§33.1–33.4The Basic Idea: An Event Loop … Why Simpler? No Locks Needed

The whole concurrency Part so far assumed one tool: threads. But they aren’t the only way. Event-based concurrency event-based concurrency A style of concurrent programming that uses no threads: a single-threaded event loop waits for events and dispatches each to a handler, one at a time. It gives the application explicit control over scheduling and needs no locks (on one CPU), at the cost of complexity around blocking calls and manual state management. Used in GUIs, servers like Flash, and node.js. defined in ch. 33 — open in glossary — used in GUIs, high-performance servers, and node.js — takes a different tack, fixing two thread headaches: getting locking correct is hard, and you have little control over scheduling.

33.1 The Basic Idea: An Event Loop

Wait for something (an event) to happen; when it does, figure out what it is and do the small bit of work it needs. The whole server is built around an event loop event loop The heart of an event-based server: while(1){ events = getEvents(); for (e in events) processEvent(e); }. It waits for events, then processes each one with its handler, one at a time. Because only one handler runs at a time, choosing which event to handle next IS scheduling. defined in ch. 33 — open in glossary :

while (1) {
    events = getEvents();
    for (e in events)
        processEvent(e);
}

The code handling each event is an event handler event handler The code that processes a single event in an event-based server. Since handlers run one at a time in a single thread, no locks are needed — but a handler must never make a blocking call, or the whole server stalls. defined in ch. 33 — open in glossary . The key insight: while a handler runs, it is the only activity in the system — so deciding which event to handle next is exactly scheduling. Watch one turn of the loop:

33.2 An Important API: select() (or poll())

How does the loop learn which events are ready — say, which sockets have an incoming packet? The select() (or poll()) system call:

int select(int nfds, fd_set *readfds, fd_set *writefds,
           fd_set *errorfds, struct timeval *timeout);

It examines sets of file descriptors and reports which are ready to read (a packet arrived), write (OK to reply), or have an error. timeout = NULL blocks until something is ready; timeout = 0 polls and returns immediately.

33.3 Using select()

Fig 33.1: each iteration clears the set (FD_ZERO), marks the descriptors of interest (FD_SET), calls select(), then checks which came back ready (FD_ISSET) and processes them:

while (1) {
    fd_set readFDs;
    FD_ZERO(&readFDs);                       // clear the set
    for (int fd = minFD; fd < maxFD; fd++)
        FD_SET(fd, &readFDs);                // mark interest

    select(maxFD+1, &readFDs, NULL, NULL, NULL);  // which are ready?

    for (int fd = minFD; fd < maxFD; fd++)
        if (FD_ISSET(fd, &readFDs))
            processFD(fd);                   // handle the ready ones
}

Step through what happens to the descriptor set:

33.4 Why Simpler? No Locks Needed

On a single CPU, the event-based approach makes concurrency bugs vanish. Because only one event is handled at a time, and the loop can’t be interrupted by another thread (it’s decidedly single-threaded), there’s no need to acquire or release locks — the races and deadlocks of the threaded world simply don’t manifest. Threads and events, side by side:

That “no locks” column is the event model’s headline win — but the “blocking calls FORBIDDEN” row is its Achilles’ heel, and the subject of the next section.