Using select()

This lesson presents an example to explain the usage of select().

We'll cover the following

To make this more concrete, let’s examine how to use select() to see which network descriptors have incoming messages upon them. The code excerpt below shows a simple example.

Press + to interact
#include <stdio.h> 

#include <stdlib.h> 

#include <sys/time.h> 

#include <sys/types.h> 

#include <unistd.h>



int main(void) {

  // open and set up a bunch of sockets (not shown)

  // main loop

  while (1) {

    // initialize the fd_set to all zero fd_set readFDs;

    fd_set readFDs;

    FD_ZERO(&readFDs);



    // now set the bits for the descriptors

    // this server is interested in

    // (for simplicity, all of them from min to max)

    int fd;

    for (fd = minFD; fd < maxFD; fd++)

        FD_SET(fd, &readFDs);



    // do the select

    int rc = select(maxFD+1, &readFDs, NULL, NULL, NULL);



    // check which actually have data using FD_ISSET()

    int fd;

    for (fd = minFD; fd < maxFD; fd++)

        if (FD_ISSET(fd, &readFDs)) 

            processFD(fd);

    } 

}

This code is actually fairly simple to understand. After some initialization, the server enters an infinite loop. Inside the loop, it uses the FD_ZERO() macro to first clear the set of file descriptors and then uses FD_SET() to include all of the file descriptors from minFD to maxFD in the set. This set of descriptors might represent, for example, all of the network sockets to which the server is paying attention. Finally, the server calls select() to see which of the connections have data available upon them. By then using FD_ISSET() in a loop, the event server can see which of the descriptors have data ready and process the incoming data.

Of course, a real server would be more complicated than this and require logic to use when sending messages, issuing disk I/O, and many other details. For further information, see Stevens and Rago“Advanced Programming in the UNIX Environment” by W. Richard Stevens and Stephen A. Rago. Addison-Wesley, 2005. Once again, we refer to the classic must-have-on-your-bookshelf book of UNIX systems programming. If there is some detail you need to know, it is in here. for API information, or Pai et. al“Flash: An Efficient and Portable Web Server” by Vivek S. Pai, Peter Druschel, Willy Zwaenepoel. USENIX ’99, Monterey, CA, June 1999. A pioneering paper on how to structure web servers in the then-burgeoning Internet era. Read it to understand the basics as well as to see the authors’ ideas on how to build hybrids when support for asynchronous I/O is lacking. or Welsh et al.“SEDA: An Architecture for Well-Conditioned, Scalable Internet Services” by Matt Welsh, David Culler, and Eric Brewer. SOSP ’01, Banff, Canada, October 2001. A nice twist on event-based serving that combines threads, queues, and event-based handling into one streamlined whole. Some of these ideas have found their way into the infrastructures of companies such as Google, Amazon, and elsewhere. for a good overview of the general flow of event-based servers.

TIP: DON’T BLOCK IN EVENT-BASED SERVERS

Event-based servers enable fine-grained control over scheduling of tasks. However, to maintain such control, no call that blocks the execution of the caller can ever be made. Failing to obey this design tip will result in a blocked event-based server, frustrated clients, and serious questions as to whether you ever read this part of the course.

Why Simpler? No Locks Needed

With a single CPU and an event-based application, the problems found in concurrent programs are no longer present. Specifically, because only one event is being handled at a time, there is no need to acquire or release locks; the event-based server cannot be interrupted by another thread because it is decidedly single-threaded. Thus, concurrency bugs common in threaded programs do not manifest in the basic event-based approach.

Get hands-on with 1400+ tech skills courses.