Re: Problems raising fd limits in 1.3.78-1.3.80

Kevin M Bealer (
Tue, 2 Apr 1996 22:23:04 -0500 (EST)

On Mon, 1 Apr 1996, David ``Joel Katz'' Schwartz wrote:

> On Mon, 1 Apr 1996 wrote:
> > It is not recommended to increase __FD_SET's size. Unfortunately,
> > however large you make it, libc simply cannot cope with a select size
> > larger than 256 fd's.
> Libc doesn't have to do anything. I just need the fdset macros to
> work and I need select to work.
> > As for the other parameters, you don't need to recompile the kernel.
> > In all post-1.3.57 kernels, you could achieve your inode and file
> > limits by (as root):
> > echo 4096 > /proc/sys/kernel/inode-max
> > echo 2048 > /proc/sys/kernel/file-max
> Yes, that does work. But without the 256 fds per process fix, I'm
> still pretty much screwed. :(
> JK

If you were willing to deal with slower access and writing some kludge code
yourself, could you 'encapsulate' the file commands such that they would be
'virtual' file descriptors? What I mean is, when one needs to open, it
calls a vfopen(), vfread(), etc instead of an fopen(), fread()... vfopen()
could close a file and open the other one, and vfread() would remember file
positions and reopen and seek to the correct position as necessary, etc.
You would need a lockopen() and unlockopen() which would make sure a file
was open when passing it's descriptor to library functions, etc... not very
elegant, come to think of it.
(just an idea... take cum grano sal :)

Quidquid latine dictum sit, altum viditur.
(Whatever is said in Latin sounds profound.)