Re: poll(2) only can handle 256 fds?

[Gus Koppel <gtk spamkiller bytechase cx>]

Iago Rubio wrote:

> > > i get the message
> > >   *** GLib *** : poll(2) failed due to: Invalid argument.
> > > thousand times when running my application.
> > > It seems that it happens if i have accepted 100 < x < 200
> > > tcp connection from which i listen for input.
> > >
> > > What can i do? I am using glib 2.6.0 on a linux system.
> >
> > I've did some investigation, and it appears that glib runs into
> > an endless loop when it tries to poll more than 256 fds at once.
>
> It makes sense ... read /usr/include/linux/limits.h 
>
> #define OPEN_MAX         256    /* # open files a process may have */
>
> It's not glib, but your kernel.
>
> If you need to open more files in a single process, change this number
> and recompile the kernel.

No need for that! Speaking of the Linux kernel, OPEN_MAX is a legacy
value without meaning any more. In Linux <= 2.2.x kernel series there
existed a hardcoded limit of 1024 (default value) file descriptors
indeed, but starting with kernel 2.4.x the number of file descriptors
has become dynamic. The initial value appears to be __FD_SETSIZE,
defined in include/linux/posix_types.h, which defaults to 1024 FDs per
process. When a process requests to open more files (connections) than
this, the kernel dynamically expands the file descriptor pool of the
process up to NR_OPEN files (include/linux/fs.h), which is about 1
million in my kernel. Since I can confirm polling of more than 1024 open
files (TCP connections) is possible on Linux, scopes of <200 must be a
limitation or bug in glib or somewhere else in Userland.

However, is it possible that you're just suffering from some lower
ulimit settings (command 'ulimit'), which may be limiting the resources
available to your program?