>> I'd also recommend changing the default FD_SETSIZE value, especially
>> if you raise the default fd limit as high as 256.
> We can't.  At least not blindly.

Well, it works, for values of "works" equaling "the webserver behaves
better now than before raising FD_SETSIZE".  Of course, that's just one
machine, with all that implies (and in particular a machine that
doesn't use anything RPC-based).

> The problem is we have library code that assumes what FD_SETSIZE is.
> I think it's the Sun RPC code.  Since the size of the set isn't
> passed in, if we just up FD_SETSIZE in libc, then we break older
> programs.

How badly?  I'd guess, based on what you've said, that it'll break
things only when programs try to use sunrpc calls with fd_sets
including descriptors above 256.

However, on looking through /usr/src/lib/libc/rpc/, I see code that
raising FD_SETSIZE will fix (in the sense of "stops it from trashing
the stack", not "removes the bug"), and I see code that can break if
it's compiled with a different FD_SETSIZE from its caller, but I see
nothing that raising FD_SETSIZE will break, provided everything is
recompiled with the new value.

Now, if you mean "raising FD_SETSIZE will break _binary_
compataibility", then yes, you are correct: if svc_getreqset is built
with a larger FD_SETSIZE than its caller, it will access beyond the
fd_set its caller passes in.  This can be fixed with symbol versioning.
I see nothing else with ABI breakage (except __svc_clean_idle, which I
assume should not be called outside libc).  There are already issues
with using sunrpc calls when using a user-raised FD_SETSIZE....

Perhaps I missed something, but I am inclined to doubt it; I tend to
trust grep. :-)

>> [...select()...poll()...]
> Use kevent().  It 1) scales very well, and 2) is much nicer.

It also appears to be kernel-internal-only, based on searching
/usr/src/share/man/ for files containing "kevent" and thus is
irrelevant to a discussion of select vs poll.

However, this has now drifted off-topic for tech-kern and arguably
should be moved to tech-userlevel instead.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B