GUI event model: synchronous or asynchronous?

From: David Turner (david_at_firepro.co.za)
Date: 10/28/03 

Date: Tue, 28 Oct 2003 15:25:08 +0200

Hi there

Imagine for a moment that you, as a programmer, could ask a genie to design
the perfect GUI. Would you ask for an asynchronous event model?

By "asynchronous", I mean the following: when the user clicks on a button,
for example, a message is dispatched to your code *on a new thread*. The
GUI keeps on processing input and drawing widgets in the background.

Contrast this with the usual approach, where the message is dispatched on
the GUI event processing thread. If you perform a blocking operation, the
GUI is blocked. Oops, probably not what you wanted - but a common mistake
nonetheless.

Of course, there is a downside to asynchronous event processing. For
example, what if the user clicks the button twice, very quickly?
Potentially so quickly that your code doesn't even have time to disable the
button? (This is possible, in fact). How should the GUI handle this?

There's also a third model which is a compromise between fully synchronous
and fully asynchronous. Here, there are exactly two threads: one for
processing user input and drawing widgets, and another for handling
higher-level events like button presses.

All opinions are welcome. What I'm trying to guage is the expectation of
programmers - which model do you subconsciously apply when writing GUI apps?

Regards
David Turner