In message <Pine.NEB.4.21.0007041613330.1884-100000@server.int.duh.org>Todd Vie
rling writes
>On Tue, 4 Jul 2000, Jonathan Stone wrote:

>This scale is something probably better suited to UDP lookups and sendto(),
>but I digress....

i would really rather not write my own resolver library.
I dunno if bind9's resolver supporsthat or not.

>I can understand that named is a possible exception, and again, you can (or
>we can, in the base source tree) modify it such that it redefines FD_SETSIZE
>to a larger number for its own use.

Yep. I sugggested that already.  Jason seems to buy it, though for
reasons I dont understand, he prefers to conceal that in public.

>This isn't like SOMAXCONN, which has to be modified at the kernel level (and
>made visible to user source).  This is an application-definable constant
>that dynamically resizes whenever you re#define it in the application.  

That works when you are *compiling applications*. It does not work
when you are using *precompiled binaries* (application or library).
There, the issue is what *NetBSD* does.

>There simply is no need to make everyone else spend more time copying mostly
>empty fd_set's when the application has a Very Simple way to increase it
>own pool.

*Shrug*. I would sooner bump NetBSD's default FD_SETSIZE, to something
more in line with what, say, Linux does. The costs on Linux are widely
accepted; and it means that any precopmiled netbsd app or library will
be able to scale up to the same number of open FD's as on, say, Linux.
That doesn't seem a-priorio outrageous or indefensible.  (I mean, its
not like I suggested using the 6k to 8k FD_SETSIZE I use myself, now
is it?)

I hope nobody from ex-CSRG is following this, but my guess is that the
limit of 256 was a seat-of-the-pants estimate of a reasonable tradeoff
at the time.  that was 10 years ago.  You can do a lot more with a
desktop workstation now. Is it still a good upper bound for
precompiled libraries, for all netbsd users?