Re: Number of File descriptors

[Dan Kegel <dank@kegel.com>]

Chuck wrote:
> Will select be ultra slow trying to select on 3000 file descriptors? 

Note that using select in a program that uses more than 1024 file 
descriptors is not completely portable; you have to redefine __FD_SETSIZE.
I have heard people say that's easy, but as recently as March 2000,
Ulrich Depper advised against it:
http://sources.redhat.com/ml/bug-glibc/2000-03/msg00051.html
As far as I can see, it's not easy on Red Hat 6.2 or 7.1.

But that's ok; you can use poll() instead.

See http://www.kegel.com/dkftpbench/Poller_bench.html for
some measurements on the speed of select() and poll() for large numbers
of file descriptors.  Here's an excerpt:

Time to select or poll n file descriptors, in microseconds,
on 650 MHz dual Pentium III with kernel 2.4.0-test10-pre4 smp:

               file descriptors
              100    1000   10000 
    select     52       -       - 
      poll     49    1184   14660 

So poll() is indeed slow at 1000 to 10000 file descriptors; whether 
it's too slow depends on your application.

> Also, what is the clarification on the kernel doing a sequential 
> search through the open file descriptors?

Yep, that's where the slowness comes from.  Linux offers several ways
around it: 
  * RT signal stuff that comes standard with 2.4
  * Provos' /dev/poll patch
  * Vitaly Luban's enhanced RT signal patch
  * Davide Libenzi's enhanced /dev/epoll patch
You can read about all of these at http://www.kegel.com/c10k.html#nb

The first has the advantage of being part of the 2.4 kernel already,
but is a bit of a pain to use (you have to handle signal overflow).
The second still has one linear scan in it, so it doesn't scale well.
The third and fourth are the top contenders for 'fastest replacement for 
select()' on Linux, but aren't part of the standard kernel yet.

- Dan