Check out the new USENIX Web site. next up previous
Next: Event-based vs. state-based notification Up: The problem with select() Previous: The problem with select()

The poll() system call

In the System V UNIX environment, applications use the poll() system call instead of select(). This call is declared as:



  struct pollfd {
        int     fd;
        short   events;
        short   revents;
  };





  int poll(
          struct pollfd filedes[];
          unsigned int nfds;
          int timeout   /* in milliseconds */);






The filedes argument is an in-out array with one element for each file descriptor of interest; nfds gives the array length. On input, the events field of each element tells the kernel which of a set of conditions are of interest for the associated file descriptor fd. On return, the revents field shows what subset of those conditions hold true. These fields represent a somewhat broader set of conditions than the three bitmaps used by select().

The poll() API appears to have two advantages over select(): its array compactly represents only the file descriptors of interest, and it does not destroy the input fields of its in-out argument. However, the former advantage is probably illusory, since select() only copies 3 bits per file descriptor, while poll() copies 64 bits. If the number of interesting descriptors exceeds 3/64 of the highest-numbered active file descriptor, poll() does more copying than select(). In any event, it shares the same scaling problem, doing work proportional to the number of interesting descriptors rather than constant effort, per event.


next up previous
Next: Event-based vs. state-based notification Up: The problem with select() Previous: The problem with select()
Gaurav Banga
1999-04-26