Re: [platform-swt-dev] MacOS X port status?

["Jeff Brown" <j9brown@xxxxxxxxxxxxxxxxx>]

Hope I get all the details right this time...

> >Combined with the fact that readAndDispatch does *not* guarantee that it
> >will return after processing a single event (it may have some others it
> >needs to process), I didn't think that I was breaking it's behavior too
> >badly.
> I've read the doc again and I think that it processes at most one OS event
> and possibly more inter-thread messages.
> May be somone from the SWT team can help?

There is no guarantee that only one event will be processed.  In the case of
modal loops, readAndDispatch() may indirectly invoke an event handler
containing its own readAndDispatch()-based modal loop.  Hence there is
no bound on the number of events processed by the call, or even on its
completion time.  Even in the absence of such nesting, the SWT
implementation
may handle an arbitrary number of events, provided the ordering of
dispatched events does not violate the event model semantics.
(i.e. can't process keyReleased before keyPressed)  The SWT Motif
implementation of readAndDispatch() may read an event of the top of
each of 3 queues to equitably deal with X events, timer events, and
auxiliary
input events (used by display.wake()) -- only processing one could lead to
short-term starvation.  Finally, there is no one-to-one correspondence
between OS events received and user events fired for obvious reasons.
On additional oddity: in the case of drag and drop on Motif with threading
enabled, the platform actually runs its own modal event loop from within
the event dispatching code!

All told, _no_ assumptions may ever be made about how many / which events
readAndDispatch() will process.  The only guarantee is that at some
time readAndDispatch() will return false to indicate that display.sleep()
should be called to block the thread instead of causing a busy wait
(since readAndDispatch() does not block if no events are pending).
The return value is not even an indicator of whether or not events were
actually processed, or whether any more are pending!

> I think nobody does anything interesting in an event loop besides having a
> special expression for terminating the loop and leaving the modal mode.

Doing anything else inside the event loop would not yield useful behaviour.
Since the readAndDispatch() runs for an indeterminate amount of time,
using the event loop body for polling or other periodic operations cannot
be guaranteed precise bounds on service time.  Better off registering a
timerExec() for these sorts of things.  Besides, doing any moderately
intensive processing within this loop could slow the application's event
processing down noticeably.

Hence, the only useful event loop for SWT is of the form:
while (someOptionalConditions && ! display.readAndDispatch())
display.sleep();

<idle_rambling>

Personally, I'm somewhat disappointed by the openness of that API
as it is error prone and not very useful except perhaps to construct
modal loops.  Invariably this amounts to nesting an event loop within
the dispatch portion of some outer event loop.  Among other things,
this means for SWT implementers that some care must be taken when
user event handlers are invoked immediately via sendEvent() instead
of being deferred via postEvent() since sendEvent() might not return
"prompty", and the message queue may be a few events shorter when
it does.

IMHO, rather than worrying about the added complexity involved with
possible nesting of event loops, perhaps some higher-level modality
support could be constructed.  Unfortunately, I can't think of any
ways to do this without breaking the SWT event model in some way.
Any ideas?

</idle_rambling>

Jeff.