Another Problem: State Management

Another issue with the event-based approach is that such code is generally more complicated to write than traditional thread-based code. The reason is that when an event handler issues an asynchronous I/O, it must package up some program state for the next event handler to use when the I/O finally completes. This additional work is not needed in thread-based programs, as the state the program needs is on the stack of the thread. Adya et al.“Cooperative Task Management Without Manual Stack Management” by Atul Adya, Jon Howell, Marvin Theimer, William J. Bolosky, John R. Douceur. USENIX ATC ’02, Monterey, CA, June 2002. This gem of a paper is the first to clearly articulate some of the difficulties of event-based concurrency, and suggests some simple solutions, as well as explores the even crazier idea of combining the two types of concurrency management into a single application! call this work manual stack management, and it is fundamental to event-based programming.

An example

To make this point more concrete, let’s look at a simple example in which a thread-based server needs to read from a file descriptor (fd) and, once complete, write the data that it read from the file to a network socket descriptor (sd). The code (ignoring error checking) looks like this: