On May 12, 2004, at 09.12, Dan Sugalski wrote:
At 2:59 PM -0400 5/11/04, Gordon Henriksen wrote:
As I pointed out in another post, this doesn't work for integrating with at least two significant "event sources:" Windows and the Mac OS. :) UI events need to be handled synchronously on the thread to which they were delivered, since the GUI APIs are not threadsafe.
Oh, it's worse than that—GUI commands need to be issued from the main thread, at least with OS X. (There's no actual requirement as to which thread handles the actual events as long as you treat the OS event queue as the thread-unsafe thing it seems to be) Or so the docs seem to indicate, though they may be a bit conservative.
That's exactly true, and exactly my point. GUI APIs are definitely not thread-safe, and for very good reasons. Not only do the system APIs essentially mandate it, but any depth of thought will make it obvious that UI events must be handled synchronously. Keeping also in mind that the main event loop stays on the execution stack, waking up to call back into event handlers; WaitNextEvent is dead. So funneling all event delivery through a Big Parrot Queue is unfeasible if your definition of "event" includes UI events. UI events, with their threading and context requirements, are really much more an issue of NCI callbacks, re-entrancy, and wrappers around system types.
That said, the technology you're proposing is still, exactly as it stands, incredibly useful:
• Asynchronous completion.
• Signal handling.
• Runtime state change notifications, for undoing speculative optimizations.
It's just not at all suitable for handling GUI events. Which is perfectly fine: Just either
1. Don't call it "events" so that people aren't disappointed and frustrated, or
2. Figure out some way to fold in GUI events.
—
Gordon Henriksen IT Manager ICLUBcentral Inc. [EMAIL PROTECTED]
