Subject: Re: increasing FD_SETSIZE to 1024 or 2048?
To: None <firstname.lastname@example.org>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 07/02/2000 16:37:15
In message <200007022317.XAA15218@orchard.arlington.ma.us>Bill Sommerfeld write
>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
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?