The control structure of an interactive program can be quite complex when implemented in a sequential language. This problem arises because interactive programs must be able to deal with asynchronous external events responsively, while also executing the application code. The usual solution to this problem is to structure the program around a central event loop, which dispatches control to parts of the application in reaction to external events. Often, the event-loop is part of a library, and applications are programmed using the so-called “inverted program structure.” This is not too bad when the application is purely reactive, that is, it only does something as a reaction to user input, but many interactive applications do not fit this model. In such cases, the application must define special call-backs to perform computation when the system is otherwise idle. In order to guarantee responsiveness, these call-backs must execute quickly and then pass control back to the event loop. In effect, the use of an event-loop is a “poor man's concurrency.” This structure makes programming computationally significant algorithms difficult, and leads to a bias towards reactive, or input-driven, systems.

A more natural way to program these systems is as a set of communicating processes. Some window systems, such as the X Window System, provide concurrency between applications by using multiple system processes, but the individual applications are sequential and suffer from the problems mentioned above.