anderss@uplog.se (07/24/90)
The subject line above says it. I'm running SunOS 4.1. I have a process
that wants to fork children (a lot of them). In order to communicate with
the children I've tried both pipes and sockets, but both tell me that I
can't have more than 64 file descriptors in one process. What I find
curious is that a quick look-around in the system header files suggest
that in 4.1 the problem is taken care of: if the process tries to open
more than 64 file descriptors, more are allocated dynamically. So, why do
pipe() and socketpair() still think that 64's the limit ? Might it be that
they still check ulimit() for the static size of the descriptor block in
the uarea ?
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...
Real life: Anders Sjolund Email: anderss@uplog.se
Snail mail: Telesoft Uppsala AB Phone: +46 18 189409
Box 1218 Fax: +46 18 132039
S - 751 42 Uppsala, Swedenguy@uunet.uu.net (Guy Harris) (07/26/90)
>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).