December 6 2006

 * Nested event handling: In the process of handling an event, it may be necessary to
obtain further information from the user.  Usually, such information is obtained via a modal
dialog; in whatever fashion the input is obtained, more user events must be received and handled
before the original event is completely handled.  To allow the further processing of events,
the handler for the original event must explicitly yield to the system.  Yielding causes events
to be handled in a nested manner, rather than in a purely sequential manner.

 * Asynchronous event handling: An application may consist of windows that represent
independent dialogs with the user.  For example, a drawing program might support multiple drawing
windows, and a particularly time-consuming task in one window(e.g.,a special filter effect on an
image) should not prevent the user from working in a different window.  Such an application needs
sequential event handling for each individual window, but asynchronous (potentiallyparallel) event
handling across windows.  In other words, the application needs a separate event queue for each
window, and a separate event-handling thread for each event queue.

  In MrEd,an eventspace is a context for processing GUI events.  Each eventspace maintains its
own queue of events, and events in a single eventspace are dispatched sequentially by a designated
handler thread.  An event-handling procedure running in this handler thread can yield to the system
by calling "yield", in which case other event-handling procedures may be called in a nested(but
single-threaded) manner within the same handler thread.  Events from different eventspaces are
dispatched asynchronously by separate handler threads.