apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Saxon Druce" <sa...@blocksoftware.com>
Subject apr_poll() with !HAVE_POLL and >FD_SETSIZE sockets
Date Tue, 13 May 2003 02:36:42 GMT

When HAVE_POLL is not defined, APR_POLL uses fd_set's to hold sockets to
pass to select(). These can only hold up to FD_SETSIZE sockets before adding
more sockets will begin overwriting other memory. On win32, FD_SETSIZE is
only 64 by default.

One way to fix this would be to add this:

    if (size > FD_SETSIZE) {
        return APR_EINVAL;

To the top of apr_poll() for !HAVE_POLL, which will return an error if
trying to poll more than FD_SETSIZE sockets. This is similar to the
following code in apr_pollset_create():

#if !defined(HAVE_POLL) && defined(FD_SETSIZE)
    if (size > FD_SETSIZE) {
        *pollset = NULL;
        return APR_EINVAL;

Another alternative would be to put something into apr_poll() which counts
the number of sockets added to each of the read, write and except sets, only
failing if more than FD_SETSIZE sockets are added to one of them. That way
in theory up to 3*FD_SETSIZE sockets could be polled at once, as long as no
more than FD_SETSIZE goes into each of the read, write and except sets.

I can provide a patch for either method if you let me know what you would

A final option, which would allow polling with >FD_SETSIZE sockets, would be
to try to dynamically allocate an fd_set which is big enough. I don't think
that could be done portably though?


View raw message