§33.5–33.9A Problem: Blocking System Calls … Summary

The event loop looked wonderful in the last section — no locks, full control. But it hides one sharp constraint.

33.5 A Problem: Blocking System Calls

What if a handler must issue a call that blocks? Say a request needs open() then read() on a file whose data isn’t in memory — those calls issue disk I/O and can take a long time. In a thread-based server this is fine: the blocked thread suspends and others run. But an event server has no other threads — just the one loop:

When the loop blocks, the whole server sits idle. Hence the iron rule: no blocking calls allowed.

33.6 A Solution: Asynchronous I/O

The fix is asynchronous I/O asynchronous i/o OS interfaces (AIO) that issue an I/O request and return control immediately, before the I/O completes, plus a way to check for completion — e.g. fill a struct aiocb, call aio_read(), then poll aio_error() (0 = done, EINPROGRESS otherwise) or receive a signal on completion. Lets an event loop issue disk I/O without blocking. defined in ch. 33 — open in glossary (AIO): interfaces that issue an I/O and return control immediately, plus a way to check for completion. On a Mac you fill a struct aiocb, then issue the read:

struct aiocb {
    int           aio_fildes;  // file descriptor
    off_t         aio_offset;  // file offset
    volatile void *aio_buf;    // destination buffer
    size_t        aio_nbytes;  // length
};

int aio_read(struct aiocb *aiocbp);   // issue; returns immediately
int aio_error(struct aiocb *aiocbp);  // 0 = done, EINPROGRESS = not yet

aio_read() returns right away, so the loop keeps serving events; later, aio_error() tells you when the data has arrived. Trace the whole non-blocking flow:

Polling dozens of outstanding I/Os with aio_error() is tedious, so many systems instead deliver a UNIX signal signal The UNIX mechanism for delivering external events to processes (SIGINT from control-c, SIGTSTP from control-z, …); sent with kill(), caught with signal(). defined in ch. 5 — open in glossary (an interrupt) when an async I/O completes — the same polling-vs-interrupts tension you’ll meet again with I/O devices.

void handle(int arg) { printf("stop wakin' me up...\n"); }

int main() {
    signal(SIGHUP, handle);
    while (1) ; // catch some sigs
}
// prompt> kill -HUP <pid>   → runs handle()

33.7 Another Problem: State Management

Event code is simply harder to write than threaded code. In a thread, reading a file then writing the result to a socket is trivial:

int rc = read(fd, buffer, size);   // when this returns...
rc = write(sd, buffer, size);      // ...sd is right here on the stack

The socket sd sits on the thread’s stack across the blocking read(). But in an event server, the handler issues the async read and returns — its stack vanishes. Adya et al. call the fix manual stack management manual stack management The burden in event-based code (named by Adya et al.) of explicitly packaging the program state needed to finish handling an event later — because, unlike a thread, there is no per-request stack holding that state across a blocking/async call. Solved with continuations. defined in ch. 33 — open in glossary : save the state you’ll need in a continuation continuation A record of the information needed to finish handling an event later — e.g. storing a socket descriptor sd in a hash table keyed by the file descriptor fd, so that when the async read on fd completes, the handler can look up where (sd) to write the data. An old programming-language idea used to solve event-based state management. defined in ch. 33 — open in glossary :

33.8 What Is Still Difficult With Events

Async I/O rescues the model, but events remain awkward in several ways:

33.9 Summary

Event-based concurrency hands scheduling control to the application, at a real cost in complexity and integration (paging, multicore, API churn). No single approach has won — threads and events both persist as two answers to the same concurrency problem. Learn both; reach for whichever fits.