In message <20000704125523.J360@dr-evil.shagadelic.org>Jason R Thorpe writes
>[ CC'd back to current-users, because it should have never been
>  removed from the CC line in the first place ... ]


Jason, deliberately and knowingly reposting private email is a gross
breach of netiquette. If you were a reasonable person, you would never
have done that; having done it, you would apologize.  Somehow, I dont
think you are going to be a reasonable person.

you also snipped, without marking, where we agreed to the idea of
raising just named's FD_SETSIZE.  That misrepresents wat was said.
Given that you are reposting private email, that's despicable.


>IPv6 support is totally optional, and does not affect every call
>to select(2) that a program might make.


I find that absurd. IPv6 support is turned on in every GENERIC kernel
we ship. turning it off means recompiling: the same kind of over head
as in either arising (or lowering) FD_SETSIZE. Using IPv6 has a bigger
cost, per packet, than clearing or setting a few extra bytes in
userspace (the copyin/copyout of lager FDsets doesnt happen until a
process actually increases its open-file limit over 64.
How many select() calls/sec does the average vax do, anyway?


>Nor do you have any hard data to show what the "sweet spot" should be
>for a general purpose operating system.

nope, nor do the people defending the status quo. thats my point.

>Consider an array of desktop workstations.  256 is more than adequate
>for systems like that.  Consider small embedded appliances.  Again,
>256 is more than adequate.
>
>Simply put, if an application knows it will have a large number of open
>descriptors, then the application should use the standards-specified
>mechanism for tuning FD_SETSIZE in a way appropriate for that application.


>If an application expects to have a large number of file descriptors,
>and does *not* use the standards-specified mechanism for tuning select(2),
>then it *is* broken.


No, Jason. It is *not* "broken".  Your argument assumes that
user-compiled apps are the *only* ones which might run into FD_SETSIZE
limits.  And I have been saying *all along* that I'm concerned about
Netbsd-shipped applications (and libraries?), *not* about
user-compiled apps.  If any such apps are ``broken'', its NetBSD's
fault for not bumping up the FD_SETSIZE in NetBSD-supplied binary apps
(and libraries, if any use select()).

If you really mean to say the NetBSD binary distributions are "broken"
for people with workloes like mine, or like large webservers, go right
ahead. Is that what you mean to say?

Maybe 256 is the right default for FD_SETSIZE. Maybe 1024 would impose
a significant overhead; maybe it wouldn't (in which case I think its a
better choice).  But you're not speaking to that.