Goal-oriented programming, or composition using events, or threads considered harmful
Robbert van Renesse · 1998
Many applications, and particularly distributed applications, are about dealing with events.The code is of the form: when this message arrives do this; when this timer expires do that; when that server fails do something else; etc.Perhaps the most natural way to program this is by using interrupt handlers.Programmers have found this hard to program, and prefer loops of the form: for ever { e = await_event () ; handle_event (e) ; }.But there are several problems with this approach.The handle_event routine may take a long time to execute, slowing down the handling of subsequent events.Worse, handle_event may invoke await_event to wait, for example, for the reply of a Remote Procedure Call.To deal with this, the thread abstraction was introduced.While threads are handling events, or awaiting for specific events, unrelated events can be handled by other threads.Unfortunately, anybody who has ever used threads extensively will agree that threads are error prone, hard to debug, and often non-portable.Composing packages that use different thread abstractions is usually not possible or extremely hard.The only widely popular language that supports threads well, Java, is still rarely used for serious distributed systems applications.Even there, simple applets that use threads oRen have bugs in them, in that they do not stop when they are off the screen, do not start up correctly when they reappear, or have race or deadlock conditions when they access shared object instances.I believe that thread_fork is the goto equivalent of parallel programming.Both request a transfer to a particular entry in your program, with no indication of scope.Once you use a bunch of these in your program, any underlying logical structure is now lost, and the program becomes hard to understand and debug.Another basic problem is that available thread synchronization paradigms are either too low-level, or too coarse-grained.Low-level mechanisms like semaphores are very error-prone.Coarse-grained mechanisms like monitors do not allow for much parallelism by overspecifying the amount of synchronization required.An alternative idea is to go back to programming directly with events.Although many event management and notification systems are under development that generate, filter, and deliver events (among many examples, Corba [5] and Yeast [4]), they do not provide much help with writing a program that takes events