> On Mon, 1 Apr 1996 sct@dcs.ed.ac.uk 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 :)
__kmb203@psu.edu_____________________________Debian/GNU__Linux__1.3.77___
Quidquid latine dictum sit, altum viditur.
(Whatever is said in Latin sounds profound.)