Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!rice!sun-spots-request
From: auspex!guy@uunet.uu.net (Guy Harris)
Newsgroups: comp.sys.sun
Subject: Re: How do I break the 64 file descriptor limit ?
Keywords: SunOS
Message-ID: <10236@brazos.Rice.edu>
Date: 25 Jul 90 18:52:04 GMT
Sender: root@rice.edu
Organization: Sun-Spots
Lines: 27
Approved: Sun-Spots@rice.edu
X-Refs:  Original: v9n277
X-Sun-Spots-Digest: Volume 9, Issue 274, message 10
Originator: spots@titan.rice.edu

>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).