Messages in this thread | | | Subject | Re: How to increse [sic.] max open files? | Date | Wed, 08 Jan 1997 15:45:36 +0100 | From | Andi Kleen <> |
| |
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
| |