In message <200007022317.XAA15218@orchard.arlington.ma.us>Bill Sommerfeld write
s

>very large descriptor sets have severe scaling problems.

I worked on this and related topics iwth Jeff Mogul at WRL last
summer-- including finding some of the bugs in the code Gaurav Banga
wrote for their Usenix paper.


>If you have a large, sparse set of descriptors, use poll(2).	

That's not really good advice.  poll() has its own problems: the
constant factor per fd is much larger than select(). and the
underlying mechanism is shared with select(0 in any case.

>If you have a large, dense set, you have an interesting interface
>design problem to make this scale well.  

Yes, I do have a large dense set. the select() api is quite reasonable
for that, given suitable hyseresis. My application code already 
shifts to a polling-based (_not_ poll()!) approach under load.
A getnextevent() interface would be nice, as would the select() 
tuning Jeff and Gaurav describe; but not really necessary.

>see solaris /dev/poll for one
>approach.  I suspect that there's lot of room for more innovation
>here.

I think we're talking at cross-purposes. I know far more about this
domain than you seem to be giving me credit for. I have already
written efficeint apps that use a thousand or so open descriptors.
I'd like to bump up FD_SETSIZE so as to let the rest of the system scale.

I appreciate your'e trying to be helpful, but your answer is a bit of
a non-sequitur. Is there some reason _not_ to bump FD_SETSIZE, given
that apps can take advanatge of FD_SETSIE on the order of 1k to 2k?