win32 poll.c

[Saxon <sa...@saxon.cx>]

Hi,

With the way apr_poll() in poll.c for win32 currently works, after the call
to select() the read, write and except sets are changed to only include the
sockets which were signalled. If you then do the apr_poll() again, it is
only polling the sockets which were signalled during the first call to
apr_poll().

Since my programme has more than one socket in the poll set, and usually
only one of them gets signalled at a time, I can't keep using apr_poll() on
the same set. To work around this, before every time I call apr_poll(), I
use apr_poll_socket_clear() to clear my poll set, then apr_poll_socket_add()
to add all of my sockets again. I'm guessing though that I shouldn't need to
do this, ie I should be able to add the socket to the poll set, and it'll
stay there until I explicitly remove it or clear the whole set.

What I imagine is that internally poll.c should work like unix's version of
poll.c which is used when HAVE_POLL is zero. In that file there are two sets
for each of read, write and except - one which stores the sockets which have
been added to the poll set, and another which has the first set copied to
it, then select() called on it, and which is then used in
apr_poll_revents_get() to see what was signalled.

If that's right, then I can write and submit a patch for this if you'd like.
If I do, should I submit the diff against what is currently in cvs, or
against my current version of poll.c, which already includes a patch I
posted a while ago, but which hasn't been checked into CVS (I don't think)?
While I'm changing poll.c, should I do anything about apr_poll_setup() not
doing anything constructive with the num parameter (which I posted an email
about a while ago)?

bye,
Saxon Druce (saxon@blocksoftware.com)