Re: How to increat [sic.] max open files - some answers

Miquel van Smoorenburg (
4 Jan 1997 20:18:09 +0100

In article <>,
Mark Hemment <> wrote:
>On Fri, 3 Jan 1997, Richard B. Johnson wrote:
>This is a little long winded, but bear with me and I'll try to reveal
>all :)
>Lets clear up one BIG misunderstanding;
> FD_SETSIZE <= sysconf(_SC_OPEN_MAX)
>Note the '<' part! (for those who write non-portable code, sysconf(...) =
>OK, under Linux FD_SETSIZE does equal the max num of open files. But try
>it out on UnixWare/Solaries (and other SVR4 derived systems). XPG/4
>states select() only supports fds upto FD_SETSIZE.

Ehm. No.

$ grep FD_SETSIZE *.h
posix_types.h:#undef __FD_SETSIZE
posix_types.h:#define __FD_SETSIZE 1024
posix_types.h:#define __FDSET_LONGS (__FD_SETSIZE/__NFDBITS)
time.h:#define FD_SETSIZE __FD_SETSIZE

FD_SETSIZE in Linux is 1024 so that all libraries and apps get used to
it. Then later in 2.1.x, OPEN_MAX will be set to 1024.

However what OpenBSD does is maybe even better. The kernel has no static
arrays of file descriptors for each process, but a linked list. OPEN_MAX
is set to 1024 or so, but you can ignore that. You'll have to raise the
limit with setrlimits() though.

In the kernel header files there is something like

#ifndef FD_SETSIZE
#define FD_SETSIZE 1024

So you can actually do:

#define FD_SETSIZE 5120
#include <sys/select.h>

Ofcourse you cannot use file descriptors > 1024 with library functions
that use select() on them, for example some of the RPC calls.

All of this is from observation of some applications, I haven't read
any kernel source yet. But it's how it could be done in Linux.

>For a complete solution, the poll() sys-call is needed (it's required by
>the latested XPG/4 spec anyway).

That's probably true


|  Miquel van Smoorenburg    | "Sticky tape is like the Force - it has a   |
| |  dark side, it has a light side, and it     |
| ----8<--------------8<---- |  holds the universe together" - Carl Zwanig |