How do I break the 64 file descriptor limit ?

[Guy Harris]

>Might it be that they still check ulimit() for the static size of
>the descriptor block in the uarea ?

Well, it's not related to "ulimit()"; however, you're at least moving in
the right general direction.

"ulimit()" is implemented atop the "resource limits" managed by
"getrlimit()" and "setrlimit()"; it's RLIMIT_FSIZE.

In 4.1 (and in System V Release 4), the maximum number of open files is
*another* limit managed by those calls - RLIMIT_NOFILE.  The "soft" limit,
which is the maximum number of open file descriptors a process can have,
is 64.  The "hard" limit is 256; to get more than 64 open, you have to use
"setrlimit()" to boost the soft limit.

>Another question, this time about lightweight processes: In 4.1 there is
>some support for lwp and asynch i/o in the kernel. Does this mean that the
>system calls that previously blocked the whole pod don't anymore ? That
>would be great...

It would, but I don't think it's true; I think the LWP support in the
kernel in 4.1 is accessible from user mode only through the asynchronous
I/O calls.  A future release might give you more general access (although
I seem to remember a Mach paper noting that you don't necessarily want to
have a one-to-one correspondence between kernel-mode and user-mode LWPs,
at least not if you then require all context switches between user-mode
LWPs to go through the kernel).