John Kohl writes:
> In the tcsh, you can use unlimit to raise the per-process FD limit up to
> the hard limit (64 is the default soft limit).

Yep, but having it at 256 may be a more reasonable default.
On the other hand, maybe daemons that need more should use setrusage
to bump up their limit.


> But as Bakul mentioned, select() won't like anything greater than 256.

It should be fixed it to be "smart" enough to work on whatever the user
has passed, rather than depending upon the FD_ macros (again, as Bakul
suggested). This way it will be dynamic (work on whatever the kernel
limit on descriptors is) like poll(2) on Solaris 2 (select(2) on Solaris 2
has the same problems with FD_SETSIZE as NetBSD's)

>From looking at kern/sys_generic.c, it may just take some work in
sys_select() && selscan(). I may look into how difficult it would be
to actually make select() more dynamic.

FYI: Solaris has a limit of 1024 for select(), and bumping the kernel's
idea of "maxfdescs" to 5120 (*) crashes stuff that uses select(),
including ypbind...

> But even if you increase FD_SETSIZE for your own program's internals,
> you have to worry about libraries which use a fixed FD_SETSIZE and
> manipulate fd_sets using descriptors beyond the FD_SETSIZE range.  This
> often makes for hard to find stack-twiddling corruption!

If select() has been modified (as above), then it shouldn't break
anything when you do bump up FD_SETSIZE. If you recompile client
programs, they'll use the higher FD's but any non-recompiled libraries
won't be able to see them, but it won't trash the stack.

If you lower FD_SETSIZE without recompling libraries you may have
problems. In this case, you might be able to prevent this by adding
an element to fd_set called "fd_size" that's set to FD_SETSIZE at
compile time, and have the FD_* macros check against that as well as
FD_SETSIZE. 
I think that this may be a lot harder to do - you could just have
a limitation that decreasing FD_SETSIZE without recompiling the
libraries may cause crashes (if the libraries call FD_COPY or FD_ZERO
on an externed fd_set from the user program that now happens to be smaller)


(*) we need 5120 (or more) fds for lockd because our application
opens ~30 NFS locks per client, with currently ~100 clients. lockd
uses poll() which doesn't have the problem select() does with
FD_SETSIZE.

-- 
Luke Mewburn <luke.mewburn@itg.telstra.com.au>

    Don't steal. The Government (and the Banks) hate competition.  - (anon)