lkml.org 
[lkml]   [1996]   [Apr]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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.)



\
 
 \ /
  Last update: 2005-03-22 13:36    [W:0.086 / U:0.288 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site