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

["Jeff Brown" <j9brown@xxxxxxxxxxxxxxxxx>]

Hiya Steve!
As always, correct me if I'm wrong...

> In fact, you are wrong - readAndDispatch performs a single read and
> dispatch event cycle for the particular operating system.

I think we're playing a definitions game here.  readAndDispatch()
performs a series of operations we can call a single "event cycle"
since there are no alternative means of breaking up the operations,
but there is still no bound on the actual number of events processed.
There's also no reason an implementation can't do multiple "event cycles"
by choice since the API semantics are very loosely defined, though
there would be no advantage that I can see to doing so.
That was more my point.

> The return value of readAndDispatch indicates that there is no more work
> for SWT to do - ie. there are no more events in the OS, no more timer
Runnables,
> no more sync/async messages.  If it's "false", SWT can go to sleep,
waiting for
> more work.

Essentially what I stated.  The implication here is that not going to sleep
(ever) would result in a busy wait at this point, which is how I phrased it.
Given timing issues, it's more of an optimization hint than anything else
since we can call display.sleep() at any time and it shouldn't actually
sleep if finds any pending events.

> // correct - exits when the conditions are met
> while (someOptionalConditions) {
>     if (!display.readAndDispatch()) display.sleep()
> }

Right, I always did get this one wrong.  I've done it before, and I'm
sure I'll do it again.  This is of course why higher level constructs are
helpful.  I feel dumb now.  =)

At any rate this is precisely what I intended as a modal loop, rather than
the Windows definition.  I hope it did not appear too ambiguous.
My problem with this type of thing and the current facilities provided
to achieve it, is that I don't believe there is much justification in
nesting event loops for this sort of thing.  It can be a problem because
you can only ever stall one code stream on one condition at a time
this way.  This interferes with the "multiple windows, perspectives, views
idea" since even though it looks like you can freely interact with objects
not subject the modal condition, you can't.  -- Like trying to pop open
file dialog boxes for two independent files simultaneously.

The only way to deal with this is to preserve execution state of stalled
operations in some other way, in Java, either by starting a new thread, or
by using the event loop the way it is intended by listening passively
for messages and pursuing the operation when the appropriate ones
have been received.  This may require setting flags to preserve mutual
exclusion semantics (disable operations that might interfere with the
one in progress).  I recently learned a new academic word: coroutine.
Good for all those things that threads really aren't.  Basically save/resume
execution state with some restrictions -- makes me think of some old
machine code tricks.

In a nutshell, this is why I think nesting of events loops should be
discouraged in favour of "friendlier" ways of solving the problem.

I'll leave the openness and style debates for the coffee table when I
see you in January since they're relevant at this time.

> I'm not sure what the discussion of "sendEvent" versus "postEvent" for the
> SWT implementor is getting at.  In fact, "postEvent" is an artifact and
there has been
> some discussion around here about getting rid of it.

We've seen problems with sendEvent().  Client registers SWT.Expand
event on Tree.  User expands TreeItem.  Tree processes event,
precomputes data needed to refresh the tree, calls the client's
SWT.Expand event handler.  Client _modifies_ Tree and returns.
Tree tries to repaint itself with stale data!  In the (not so)
extreme case, the client may go off and run a nested event loop.
Not an uncommon occurrence with things like SWT.DefaultSelected.
So sendEvent() must be handled carefully.  That was my point.

Mixing postEvent() with sendEvent() is worse since events may
be sent back to the client in non-FIFO order unless we force
all posted events to be processed before a new sendEvent()
occurs and perhaps before any other OS events.
[Alternately, implement sendEvent() as postEvent() +
flush... or something similar]  Since SWT relies on immediate reply
data from some events (e.g. DND), we must keep sendEvent().
I don't see postEvent() as being particularly harmful if it's
handled properly...  It seems a rather useful tool to avoid scenarios
like the one with Tree above.  Have I missed something?

Jeff.