Event-architecture & concurrency
Is there a conceptual difference between concurrent GUI programming and other types of concurrent programming?
Sometime a GUI pops up modal dialog (Ex. Save file as...) that blocks access to the rest of the user interface until that dialog is dismissed.
Other times clicking a button may turn the mouse cursor into an hourglass and block mouse/keyboard input until the button action completes (this is done so the user cannot repeatedly click the button until the task completes).
Blocking the user from interacting with parts of the user interface appear to be similar to the idea of critical sections. Normally critical sections allow one thread at a time to execute them. In the GUI examples, we want the sections to only allow events dispatched from any source but exclude events from the "user" source.
This is usually done by pushing/popping event queues (in the case of the modal dialog), or discarding events (in the case of hourglass/input blocking).
Just curious if anyone has thoughts on how things like locks, barriers, futures, exchangers, etc, work at a macroscopic level in the GUI domain.
