Rather than storing and restoring machine registers to pause and resume execution, the program can be divided into pieces each of which manually stores and restores their state. A single ``scheduler'' routine then provides the glue to execute these pieces in the appropriate sequence. For example, rather than making a blocking call, the event-driven style would post an asynchronous request, then explicitly return control back to the scheduler. Once the request completes, the scheduler will call the object again to resume execution. We have explored this idea in Charm++ runtime system [24] extensively.
This ``event-driven'' style avoids operating system and other low-level problems completely. Because suspending and resuming execution is simply a function call, the event-driven style can also be very efficient.
However, the event-driven style can be more difficult for programmers. In
particular, if it becomes necessary to block from inside a deeply
nested subroutine call, all the calling routines must be changed to
pass control back up to the scheduler.
Also, a reactive and event-driven style of programming obscures the
description of the life-cycle of an object. For example, a program
would specify that when this message A arrives, execute method F; when B
arrives, execute G, but can not specify that the object is going to
repeatedly process 
and 
messages in alternating sequence 
times
[32].