Messages in this thread | | | Date | Tue, 2 Apr 1996 22:23:04 -0500 (EST) | From | Kevin M Bealer <> | Subject | Re: Problems raising fd limits in 1.3.78-1.3.80 |
| |
On Mon, 1 Apr 1996, David ``Joel Katz'' Schwartz wrote:
> 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.)
| |