Re: How to increse [sic.] max open files?
Andi Kleen (andi@mlm.extern.lrz-muenchen.de)
Wed, 08 Jan 1997 15:45:36 +0100
In message <Mutt.19970108110038.chexum@bankinf.banki.hu>you write:
>Andi Kleen writes:
>> smurf@work.smurf.noris.de (Matthias Urlichs) writes:
>> > 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.
>
>I don't really need poll() is needed [which means I never saw that.. :)].
>The only problem with the select() interface, that the kernel doesn't know
>about how many fd's *can* be in the fd_set the app just passed to it. It
>already supports more, and you just fixed it to be even more.. So,
>I think everything would be solved by a new syscall, maybe select_n,
>select_any, __select_n, or something, which has the first arg of the
>maximum fd's the process supports at the time of compiling... It can also
>be made transparent through libc hacks/macros, the end result is that "new"
>apps would work something like this:
>
The BSD people already had this idea when they designed select() ;) See select(2).
poll() is needed for the POSIX.1g and XPG4 standard compliance anyways I think so
it will come sooner or later.
>#define __FD_SETSIZE MYAPPNEEDTHISMUCH
>#include <sys/time.h> /* or whereever that header is.. :) */
That works with my patch, but not with the current kernel (it does
a #undef __FD_SETSIZE before defining it. I changed this.
The major problem with all this (as Alan Cox mentioned) is what happens
when you fork a program that is compiled with a small __FD_SETSIZE
and the program tries to use a passed fd selector that is bigger
than its fd_set. I see no way around this other than recompiling.
It's an obscure case anyway.
-Andi