>> > I'd rather have the FD_ZERO fixed to take the size of the fd_set as
>> > a explicit parameter.
>
>> If we're going to abandon the current select() interface, the right
>> answer is to the use the SVR4 poll(), one of the few things System V
>> did much better than BSD.
>
>> (There's the minor weakness that it uses a
>> millisecond timeout, but that's much less of a flaw than those of the
>> select() interface.)
>
>I didn't propose to abandon the current select() interface.  Quite the
>contrary, actually.
>
>I don't see a significant functional difference between poll() and
>select().  Only minor stylistic differences.  What, exactly, are the
>major flaws in the select() interface that poll() hasn't?

I think what Greg means is that with poll, you provide an array of
"struct pollfd", and the number of descriptors in that array.  Thus, if you
want to look at fd's 2, 3, 4, 5, and 127, it only needs to look at 5 things.

With select, you give it a bitmask and the highest-valued fd in that bitmask
(actually, it might be the highest-valued plus 1).  Thus, if you want to
look at fd's 2, 3, 4, 5, and 127, the kernel has to scan all the bits between
5 and 127 in your bitmask.  With select, it's slightly easier to quickly check
to see if something happened on your fd (with poll, you either have to scan
them all, or remember where in the array you stored that fd).

However, I don't see the interfaces as being incompatible - I think that
other than the 128 fd limit on select and the ms resolution on poll, you
could implement one with the other.

Assuming that all applications use the FD_* macros, it seems that it would
be possible to make fdsets some sort of opaque objects that don't have
the current limitations.  Some other people have already given some good
starts on this idea.

--Ken