overflowtext="",overflowoffset=0
date:component="Your message dated",formatfield=""
body:component=">",overflowtext=">",overflowoffset=0
In message <200007031625.SAA13414@kurt.tools.de>Wolfgang Solfrank writes
>Hi,
>
>> FD_SETSIZE is currently 256. Is there a good reason not to bump it to
>> something more appropriate for today's machines, like 1024 or 2048?
>
>[...]
>
>> So it has a big potential payback for those who want it, at
>> relatively little cost. 
>
>Are you aware that there is nothing to stop an application to use
>a larger FD_SETSIZE if it so desires?  [...]

I mentioned that in my original email.  I dont see how
I can mention something without aware of it...



>IMHO that's flexible enough to get the best of both worlds (i.e. space
>savings in small applications vs. support for many connections in large
>ones).

No, it doesn't, Not unless you are prepared to recompile all of
NetBSD's userland to match the higher open-fd limits.  named is my
current pet example: the low value on FD_SETSIZE in named limits the
application performance of my applications.

That recompilation (and maintaining it in source form in local trees)
is exactly what I was trying to avoid.


FWIW, Linux ships with FD_SETSIZE = 1024 and has done for years.