nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-09 17:38:00 +00:00
Code Issues Projects Releases Wiki Activity
3c6ab5bbb7
putty-source/unix/uxpoll.c

170 lines
3.9 KiB
C
Raw Normal View History

uxpoll.c: cope with missing #defines in poll.h. Baruch Siach reports that in a uClibc-ng build environment, POLLRDNORM and friends are only defined by poll.h if you #define _XOPEN_SOURCE before including it. So now we do that, in case it helps - and we also cope with those #defines still being absent, in case on some other system even that doesn't help.
2019-03-26 18:37:26 +00:00
/* On some systems this is needed to get poll.h to define eg.. POLLRDNORM */
#define _XOPEN_SOURCE
Switch to using poll(2) in place of select(2). I've always thought poll was more hassle to set up, because if you want to reuse part of your pollfds list between calls then you have to index every fd by its position in the list as well as the fd number itself, which gives you twice as many indices to keep track of than if the fd is always its own key. But the problem is that select is fundamentally limited to the range of fds that can fit in an fd_set, which is not the range of fds that can _exist_, so I've had a change of heart and now have to go with poll. For the moment, I've surrounded it with a 'pollwrapper' structure that lets me treat it more or less like select, containing a tree234 that maps each fd to its location in the list, and also translating between the simple select r/w/x classification and the richer poll flags. That's let me do the migration with minimal disruption to the call sites. In future perhaps I can start using poll more directly, and/or using the richer flag system (though the latter might be fiddly because of sometimes being constrained to use the glib event loop). But this will do for now.
2019-02-07 18:21:06 +00:00
#include <poll.h>
#include "putty.h"
#include "tree234.h"
struct pollwrapper {
struct pollfd *fds;
size_t nfd, fdsize;
tree234 *fdtopos;
};
typedef struct pollwrap_fdtopos pollwrap_fdtopos;
struct pollwrap_fdtopos {
int fd;
size_t pos;
};
static int pollwrap_fd_cmp(void *av, void *bv)
{
pollwrap_fdtopos *a = (pollwrap_fdtopos *)av;
pollwrap_fdtopos *b = (pollwrap_fdtopos *)bv;
return a->fd < b->fd ? -1 : a->fd > b->fd ? +1 : 0;
}
pollwrapper *pollwrap_new(void)
{
pollwrapper *pw = snew(pollwrapper);
pw->fdsize = 16;
pw->nfd = 0;
pw->fds = snewn(pw->fdsize, struct pollfd);
pw->fdtopos = newtree234(pollwrap_fd_cmp);
return pw;
}
void pollwrap_free(pollwrapper *pw)
{
pollwrap_clear(pw);
freetree234(pw->fdtopos);
sfree(pw->fds);
sfree(pw);
}
void pollwrap_clear(pollwrapper *pw)
{
pw->nfd = 0;
for (pollwrap_fdtopos *f2p;
(f2p = delpos234(pw->fdtopos, 0)) != NULL ;)
sfree(f2p);
}
void pollwrap_add_fd_events(pollwrapper *pw, int fd, int events)
{
pollwrap_fdtopos *f2p, f2p_find;
assert(fd >= 0);
f2p_find.fd = fd;
f2p = find234(pw->fdtopos, &f2p_find, NULL);
if (!f2p) {
sgrowarray(pw->fds, pw->fdsize, pw->nfd);
size_t index = pw->nfd++;
pw->fds[index].fd = fd;
pw->fds[index].events = pw->fds[index].revents = 0;
f2p = snew(pollwrap_fdtopos);
f2p->fd = fd;
f2p->pos = index;
pollwrap_fdtopos *added = add234(pw->fdtopos, f2p);
assert(added == f2p);
}
pw->fds[f2p->pos].events |= events;
}
uxpoll.c: cope with missing #defines in poll.h. Baruch Siach reports that in a uClibc-ng build environment, POLLRDNORM and friends are only defined by poll.h if you #define _XOPEN_SOURCE before including it. So now we do that, in case it helps - and we also cope with those #defines still being absent, in case on some other system even that doesn't help.
2019-03-26 18:37:26 +00:00
/* Omit any of the POLL{RD,WR}{NORM,BAND} flag values that are still
* not defined by poll.h, just in case */
#ifndef POLLRDNORM
#define POLLRDNORM 0
#endif
#ifndef POLLRDBAND
#define POLLRDBAND 0
#endif
#ifndef POLLWRNORM
#define POLLWRNORM 0
#endif
#ifndef POLLWRBAND
#define POLLWRBAND 0
#endif
Switch to using poll(2) in place of select(2). I've always thought poll was more hassle to set up, because if you want to reuse part of your pollfds list between calls then you have to index every fd by its position in the list as well as the fd number itself, which gives you twice as many indices to keep track of than if the fd is always its own key. But the problem is that select is fundamentally limited to the range of fds that can fit in an fd_set, which is not the range of fds that can _exist_, so I've had a change of heart and now have to go with poll. For the moment, I've surrounded it with a 'pollwrapper' structure that lets me treat it more or less like select, containing a tree234 that maps each fd to its location in the list, and also translating between the simple select r/w/x classification and the richer poll flags. That's let me do the migration with minimal disruption to the call sites. In future perhaps I can start using poll more directly, and/or using the richer flag system (though the latter might be fiddly because of sometimes being constrained to use the glib event loop). But this will do for now.
2019-02-07 18:21:06 +00:00
#define SELECT_R_IN (POLLIN | POLLRDNORM | POLLRDBAND)
#define SELECT_W_IN (POLLOUT | POLLWRNORM | POLLWRBAND)
#define SELECT_X_IN (POLLPRI)
#define SELECT_R_OUT (SELECT_R_IN | POLLERR | POLLHUP)
#define SELECT_W_OUT (SELECT_W_IN | POLLERR)
#define SELECT_X_OUT (SELECT_X_IN)
void pollwrap_add_fd_rwx(pollwrapper *pw, int fd, int rwx)
{
int events = 0;
if (rwx & SELECT_R)
events |= SELECT_R_IN;
if (rwx & SELECT_W)
events |= SELECT_W_IN;
if (rwx & SELECT_X)
events |= SELECT_X_IN;
pollwrap_add_fd_events(pw, fd, events);
}
int pollwrap_poll_instant(pollwrapper *pw)
{
return poll(pw->fds, pw->nfd, 0);
}
int pollwrap_poll_endless(pollwrapper *pw)
{
return poll(pw->fds, pw->nfd, -1);
}
int pollwrap_poll_timeout(pollwrapper *pw, int milliseconds)
{
assert(milliseconds >= 0);
return poll(pw->fds, pw->nfd, milliseconds);
}
pollwrap: stop returning unasked-for rwx statuses. The sets of poll(2) events that we check in order to return SELECT_R and SELECT_W overlap: to be precise, they have POLLERR in common. So if an fd signals POLLERR, then pollwrap_get_fd_rwx will respond by saying that it has both SELECT_R and SELECT_W available on it - even if the caller had only asked for one of those. In other words, you can get a spurious SELECT_W notification on an fd that you never asked for SELECT_W on in the first place. This definitely isn't what I'd meant that API to do. In particular, if a socket in the middle of an asynchronous connect() signals POLLERR, then Unix Plink will call select_result for it with SELECT_R and then SELECT_W respectively. The former will notice that it's got an error condition and call plug_closing - and _then_ the latter will decide that it's writable and set s->connected! The plan was to only select it for write until it was connected, but this bug in pollwrap was defeating that plan. Now pollwrap_get_fd_rwx should only ever return a set of rwx flags that's a subset of the one that the client asked for via pollwrap_add_fd_rwx.
2020-02-06 23:48:36 +00:00
static void pollwrap_get_fd_events_revents(pollwrapper *pw, int fd,
int *events_p, int *revents_p)
Switch to using poll(2) in place of select(2). I've always thought poll was more hassle to set up, because if you want to reuse part of your pollfds list between calls then you have to index every fd by its position in the list as well as the fd number itself, which gives you twice as many indices to keep track of than if the fd is always its own key. But the problem is that select is fundamentally limited to the range of fds that can fit in an fd_set, which is not the range of fds that can _exist_, so I've had a change of heart and now have to go with poll. For the moment, I've surrounded it with a 'pollwrapper' structure that lets me treat it more or less like select, containing a tree234 that maps each fd to its location in the list, and also translating between the simple select r/w/x classification and the richer poll flags. That's let me do the migration with minimal disruption to the call sites. In future perhaps I can start using poll more directly, and/or using the richer flag system (though the latter might be fiddly because of sometimes being constrained to use the glib event loop). But this will do for now.
2019-02-07 18:21:06 +00:00
{
pollwrap_fdtopos *f2p, f2p_find;
pollwrap: stop returning unasked-for rwx statuses. The sets of poll(2) events that we check in order to return SELECT_R and SELECT_W overlap: to be precise, they have POLLERR in common. So if an fd signals POLLERR, then pollwrap_get_fd_rwx will respond by saying that it has both SELECT_R and SELECT_W available on it - even if the caller had only asked for one of those. In other words, you can get a spurious SELECT_W notification on an fd that you never asked for SELECT_W on in the first place. This definitely isn't what I'd meant that API to do. In particular, if a socket in the middle of an asynchronous connect() signals POLLERR, then Unix Plink will call select_result for it with SELECT_R and then SELECT_W respectively. The former will notice that it's got an error condition and call plug_closing - and _then_ the latter will decide that it's writable and set s->connected! The plan was to only select it for write until it was connected, but this bug in pollwrap was defeating that plan. Now pollwrap_get_fd_rwx should only ever return a set of rwx flags that's a subset of the one that the client asked for via pollwrap_add_fd_rwx.
2020-02-06 23:48:36 +00:00
int events = 0, revents = 0;
Switch to using poll(2) in place of select(2). I've always thought poll was more hassle to set up, because if you want to reuse part of your pollfds list between calls then you have to index every fd by its position in the list as well as the fd number itself, which gives you twice as many indices to keep track of than if the fd is always its own key. But the problem is that select is fundamentally limited to the range of fds that can fit in an fd_set, which is not the range of fds that can _exist_, so I've had a change of heart and now have to go with poll. For the moment, I've surrounded it with a 'pollwrapper' structure that lets me treat it more or less like select, containing a tree234 that maps each fd to its location in the list, and also translating between the simple select r/w/x classification and the richer poll flags. That's let me do the migration with minimal disruption to the call sites. In future perhaps I can start using poll more directly, and/or using the richer flag system (though the latter might be fiddly because of sometimes being constrained to use the glib event loop). But this will do for now.
2019-02-07 18:21:06 +00:00
assert(fd >= 0);
f2p_find.fd = fd;
f2p = find234(pw->fdtopos, &f2p_find, NULL);
pollwrap: stop returning unasked-for rwx statuses. The sets of poll(2) events that we check in order to return SELECT_R and SELECT_W overlap: to be precise, they have POLLERR in common. So if an fd signals POLLERR, then pollwrap_get_fd_rwx will respond by saying that it has both SELECT_R and SELECT_W available on it - even if the caller had only asked for one of those. In other words, you can get a spurious SELECT_W notification on an fd that you never asked for SELECT_W on in the first place. This definitely isn't what I'd meant that API to do. In particular, if a socket in the middle of an asynchronous connect() signals POLLERR, then Unix Plink will call select_result for it with SELECT_R and then SELECT_W respectively. The former will notice that it's got an error condition and call plug_closing - and _then_ the latter will decide that it's writable and set s->connected! The plan was to only select it for write until it was connected, but this bug in pollwrap was defeating that plan. Now pollwrap_get_fd_rwx should only ever return a set of rwx flags that's a subset of the one that the client asked for via pollwrap_add_fd_rwx.
2020-02-06 23:48:36 +00:00
if (f2p) {
events = pw->fds[f2p->pos].events;
revents = pw->fds[f2p->pos].revents;
}
if (events_p)
*events_p = events;
if (revents_p)
*revents_p = revents;
}
Switch to using poll(2) in place of select(2). I've always thought poll was more hassle to set up, because if you want to reuse part of your pollfds list between calls then you have to index every fd by its position in the list as well as the fd number itself, which gives you twice as many indices to keep track of than if the fd is always its own key. But the problem is that select is fundamentally limited to the range of fds that can fit in an fd_set, which is not the range of fds that can _exist_, so I've had a change of heart and now have to go with poll. For the moment, I've surrounded it with a 'pollwrapper' structure that lets me treat it more or less like select, containing a tree234 that maps each fd to its location in the list, and also translating between the simple select r/w/x classification and the richer poll flags. That's let me do the migration with minimal disruption to the call sites. In future perhaps I can start using poll more directly, and/or using the richer flag system (though the latter might be fiddly because of sometimes being constrained to use the glib event loop). But this will do for now.
2019-02-07 18:21:06 +00:00
pollwrap: stop returning unasked-for rwx statuses. The sets of poll(2) events that we check in order to return SELECT_R and SELECT_W overlap: to be precise, they have POLLERR in common. So if an fd signals POLLERR, then pollwrap_get_fd_rwx will respond by saying that it has both SELECT_R and SELECT_W available on it - even if the caller had only asked for one of those. In other words, you can get a spurious SELECT_W notification on an fd that you never asked for SELECT_W on in the first place. This definitely isn't what I'd meant that API to do. In particular, if a socket in the middle of an asynchronous connect() signals POLLERR, then Unix Plink will call select_result for it with SELECT_R and then SELECT_W respectively. The former will notice that it's got an error condition and call plug_closing - and _then_ the latter will decide that it's writable and set s->connected! The plan was to only select it for write until it was connected, but this bug in pollwrap was defeating that plan. Now pollwrap_get_fd_rwx should only ever return a set of rwx flags that's a subset of the one that the client asked for via pollwrap_add_fd_rwx.
2020-02-06 23:48:36 +00:00
int pollwrap_get_fd_events(pollwrapper *pw, int fd)
{
int revents;
pollwrap_get_fd_events_revents(pw, fd, NULL, &revents);
return revents;
Switch to using poll(2) in place of select(2). I've always thought poll was more hassle to set up, because if you want to reuse part of your pollfds list between calls then you have to index every fd by its position in the list as well as the fd number itself, which gives you twice as many indices to keep track of than if the fd is always its own key. But the problem is that select is fundamentally limited to the range of fds that can fit in an fd_set, which is not the range of fds that can _exist_, so I've had a change of heart and now have to go with poll. For the moment, I've surrounded it with a 'pollwrapper' structure that lets me treat it more or less like select, containing a tree234 that maps each fd to its location in the list, and also translating between the simple select r/w/x classification and the richer poll flags. That's let me do the migration with minimal disruption to the call sites. In future perhaps I can start using poll more directly, and/or using the richer flag system (though the latter might be fiddly because of sometimes being constrained to use the glib event loop). But this will do for now.
2019-02-07 18:21:06 +00:00
}
int pollwrap_get_fd_rwx(pollwrapper *pw, int fd)
{
pollwrap: stop returning unasked-for rwx statuses. The sets of poll(2) events that we check in order to return SELECT_R and SELECT_W overlap: to be precise, they have POLLERR in common. So if an fd signals POLLERR, then pollwrap_get_fd_rwx will respond by saying that it has both SELECT_R and SELECT_W available on it - even if the caller had only asked for one of those. In other words, you can get a spurious SELECT_W notification on an fd that you never asked for SELECT_W on in the first place. This definitely isn't what I'd meant that API to do. In particular, if a socket in the middle of an asynchronous connect() signals POLLERR, then Unix Plink will call select_result for it with SELECT_R and then SELECT_W respectively. The former will notice that it's got an error condition and call plug_closing - and _then_ the latter will decide that it's writable and set s->connected! The plan was to only select it for write until it was connected, but this bug in pollwrap was defeating that plan. Now pollwrap_get_fd_rwx should only ever return a set of rwx flags that's a subset of the one that the client asked for via pollwrap_add_fd_rwx.
2020-02-06 23:48:36 +00:00
int events, revents;
pollwrap_get_fd_events_revents(pw, fd, &events, &revents);
Switch to using poll(2) in place of select(2). I've always thought poll was more hassle to set up, because if you want to reuse part of your pollfds list between calls then you have to index every fd by its position in the list as well as the fd number itself, which gives you twice as many indices to keep track of than if the fd is always its own key. But the problem is that select is fundamentally limited to the range of fds that can fit in an fd_set, which is not the range of fds that can _exist_, so I've had a change of heart and now have to go with poll. For the moment, I've surrounded it with a 'pollwrapper' structure that lets me treat it more or less like select, containing a tree234 that maps each fd to its location in the list, and also translating between the simple select r/w/x classification and the richer poll flags. That's let me do the migration with minimal disruption to the call sites. In future perhaps I can start using poll more directly, and/or using the richer flag system (though the latter might be fiddly because of sometimes being constrained to use the glib event loop). But this will do for now.
2019-02-07 18:21:06 +00:00
int rwx = 0;
pollwrap: stop returning unasked-for rwx statuses. The sets of poll(2) events that we check in order to return SELECT_R and SELECT_W overlap: to be precise, they have POLLERR in common. So if an fd signals POLLERR, then pollwrap_get_fd_rwx will respond by saying that it has both SELECT_R and SELECT_W available on it - even if the caller had only asked for one of those. In other words, you can get a spurious SELECT_W notification on an fd that you never asked for SELECT_W on in the first place. This definitely isn't what I'd meant that API to do. In particular, if a socket in the middle of an asynchronous connect() signals POLLERR, then Unix Plink will call select_result for it with SELECT_R and then SELECT_W respectively. The former will notice that it's got an error condition and call plug_closing - and _then_ the latter will decide that it's writable and set s->connected! The plan was to only select it for write until it was connected, but this bug in pollwrap was defeating that plan. Now pollwrap_get_fd_rwx should only ever return a set of rwx flags that's a subset of the one that the client asked for via pollwrap_add_fd_rwx.
2020-02-06 23:48:36 +00:00
if ((events & POLLIN) && (revents & SELECT_R_OUT))
Switch to using poll(2) in place of select(2). I've always thought poll was more hassle to set up, because if you want to reuse part of your pollfds list between calls then you have to index every fd by its position in the list as well as the fd number itself, which gives you twice as many indices to keep track of than if the fd is always its own key. But the problem is that select is fundamentally limited to the range of fds that can fit in an fd_set, which is not the range of fds that can _exist_, so I've had a change of heart and now have to go with poll. For the moment, I've surrounded it with a 'pollwrapper' structure that lets me treat it more or less like select, containing a tree234 that maps each fd to its location in the list, and also translating between the simple select r/w/x classification and the richer poll flags. That's let me do the migration with minimal disruption to the call sites. In future perhaps I can start using poll more directly, and/or using the richer flag system (though the latter might be fiddly because of sometimes being constrained to use the glib event loop). But this will do for now.
2019-02-07 18:21:06 +00:00
rwx |= SELECT_R;
pollwrap: stop returning unasked-for rwx statuses. The sets of poll(2) events that we check in order to return SELECT_R and SELECT_W overlap: to be precise, they have POLLERR in common. So if an fd signals POLLERR, then pollwrap_get_fd_rwx will respond by saying that it has both SELECT_R and SELECT_W available on it - even if the caller had only asked for one of those. In other words, you can get a spurious SELECT_W notification on an fd that you never asked for SELECT_W on in the first place. This definitely isn't what I'd meant that API to do. In particular, if a socket in the middle of an asynchronous connect() signals POLLERR, then Unix Plink will call select_result for it with SELECT_R and then SELECT_W respectively. The former will notice that it's got an error condition and call plug_closing - and _then_ the latter will decide that it's writable and set s->connected! The plan was to only select it for write until it was connected, but this bug in pollwrap was defeating that plan. Now pollwrap_get_fd_rwx should only ever return a set of rwx flags that's a subset of the one that the client asked for via pollwrap_add_fd_rwx.
2020-02-06 23:48:36 +00:00
if ((events & POLLOUT) && (revents & SELECT_W_OUT))
Switch to using poll(2) in place of select(2). I've always thought poll was more hassle to set up, because if you want to reuse part of your pollfds list between calls then you have to index every fd by its position in the list as well as the fd number itself, which gives you twice as many indices to keep track of than if the fd is always its own key. But the problem is that select is fundamentally limited to the range of fds that can fit in an fd_set, which is not the range of fds that can _exist_, so I've had a change of heart and now have to go with poll. For the moment, I've surrounded it with a 'pollwrapper' structure that lets me treat it more or less like select, containing a tree234 that maps each fd to its location in the list, and also translating between the simple select r/w/x classification and the richer poll flags. That's let me do the migration with minimal disruption to the call sites. In future perhaps I can start using poll more directly, and/or using the richer flag system (though the latter might be fiddly because of sometimes being constrained to use the glib event loop). But this will do for now.
2019-02-07 18:21:06 +00:00
rwx |= SELECT_W;
pollwrap: stop returning unasked-for rwx statuses. The sets of poll(2) events that we check in order to return SELECT_R and SELECT_W overlap: to be precise, they have POLLERR in common. So if an fd signals POLLERR, then pollwrap_get_fd_rwx will respond by saying that it has both SELECT_R and SELECT_W available on it - even if the caller had only asked for one of those. In other words, you can get a spurious SELECT_W notification on an fd that you never asked for SELECT_W on in the first place. This definitely isn't what I'd meant that API to do. In particular, if a socket in the middle of an asynchronous connect() signals POLLERR, then Unix Plink will call select_result for it with SELECT_R and then SELECT_W respectively. The former will notice that it's got an error condition and call plug_closing - and _then_ the latter will decide that it's writable and set s->connected! The plan was to only select it for write until it was connected, but this bug in pollwrap was defeating that plan. Now pollwrap_get_fd_rwx should only ever return a set of rwx flags that's a subset of the one that the client asked for via pollwrap_add_fd_rwx.
2020-02-06 23:48:36 +00:00
if ((events & POLLPRI) && (revents & SELECT_X_OUT))
Switch to using poll(2) in place of select(2). I've always thought poll was more hassle to set up, because if you want to reuse part of your pollfds list between calls then you have to index every fd by its position in the list as well as the fd number itself, which gives you twice as many indices to keep track of than if the fd is always its own key. But the problem is that select is fundamentally limited to the range of fds that can fit in an fd_set, which is not the range of fds that can _exist_, so I've had a change of heart and now have to go with poll. For the moment, I've surrounded it with a 'pollwrapper' structure that lets me treat it more or less like select, containing a tree234 that maps each fd to its location in the list, and also translating between the simple select r/w/x classification and the richer poll flags. That's let me do the migration with minimal disruption to the call sites. In future perhaps I can start using poll more directly, and/or using the richer flag system (though the latter might be fiddly because of sometimes being constrained to use the glib event loop). But this will do for now.
2019-02-07 18:21:06 +00:00
rwx |= SELECT_X;
return rwx;
}
Reference in New Issue Copy Permalink