lkml.org 
[lkml]   [1997]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: How to increse [sic.] max open files?
From
Date
smurf@work.smurf.noris.de (Matthias Urlichs) writes:

> In linux.dev.kernel, article <5andlm$ikg@palladium.transmeta.com>,
> hpa@transmeta.com (H. Peter Anvin) writes:
> > By author: yuri@rgti.com (yuri mironoff)
> > >
> > > Forgive my ignorance but why not implement dynamic file descriptor
> > > allocation??? All these arguments about a maximum NR_OPEN would then
> > > become inconsequential.
> >
> > It ain't so easy, and it's BSD's fault. select() has a very nice way
> > to ensure that a bitmask of file descriptors is the right size, but
> > the FD_* support routines immediately bungles that very nice idea by
> > effectively requiring the maximum number of file descriptors
> > (technically, the largest possible numerical value of a file
> > descriptor) to be known at compile time. There is no way in C to
>
> This is the kernel mailing list. The first step is to fix the kernel,
> including 2.0.27+, to support "unlimited" fd_sets. This hasn't happened
> yet. (Somebody said he's working on this..?)

I have a select() routine now that supports unlimited fd_sets (better
ulimited NR_OPEN). I also have some patches that add a per process
nr_open with a /proc/sys/kernel/nr-open, so you can just do
echo 8192 >/proc/sys/kernel/nr-open and all processes forked after
this will have a bigger file table. You still have to recompile
the applications of course, when you want NR_OPEN > 1024 but
that's painless (just add -D__FD_SETSIZE=4096 to CFLAGS). When anybody
is interested in alpha patches mail me. It works on my machine but
is not extensively tested.

What I would like to see in 2.1 was the addition of poll() to the
standard kernel. The sparc port already has it (in
arch/sparc/kernel/sys_sunos.c), iBCS has it too, only native i386
Linux programs can't use it. The poll() interface supports an
arbitary number of fds.


-Andi



>
> After that has happened, we can think about application programs.
> Most programs won't ever open more files than the default FD_SETSIZE.
> Those that do should just define a reasonable maximum they can handle,
> or allocate the fd_set buffers themselves (it's not that difficult even if
> you don't use C++).
>
> --
> For the first time we have a weapon that nobody has used for thirty years.
> This gives me great hope for the human race.
> --Harlan Ellison
> --
> Matthias Urlichs \ noris network GmbH / Xlink-POP Nürnberg
> Schleiermacherstraße 12 \ Linux+Internet / EMail: urlichs@noris.de
> 90491 Nürnberg (Germany) \ Consulting+Programming+Networking+etc'ing
> PGP: 1024/4F578875 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE
> Click <A HREF="http://info.noris.de/~smurf/finger">here</A>. 42

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