Number of 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.

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