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?


It's easy enough to configure kernels to allow 1024 or 2048 or even
more simultaneous open fds, or evne sycstl it. . (I run one kernel
with about 6k).  Redefininig FD_SETSIZE to 1024 or 2048 increases the
limit for select() &c for a given app.  But then I find in run into
limits due to the system-dfault FD_SETSIZE-- e.g., in named.

The way I see it, increasing FD_SETSIZE would have a very small space
penalty, a small time penalty for fd-set ops (copying 32 bytes rather
than 8), but the user/kernel interface costs are small-to-zero unless
one explicitly ups the per-process descriptors limit: since
sys_select() clips at fd_nfiles.

So it has a big potential payback for those who want it, at
relatively little cost. 

Comments?