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

["Steve Northover/OTT/OTI" <Steve_Northover@xxxxxxx>]

So, Jeff we meet again, Obi-Wan has taught you well ... feel the power of
the Dark Side ... but don't be seduced!

Sorry, we are not playing a definitions game.  I repeat, exactly one OS event
is dispatched by readAndDispatch, even on Motif where you seem to think
that something different happens.  Again, "timer" and "alternate input" are
not considered to be SWT "events" - they do not generate an SWT Event
and are private Motif concepts that do not concern an SWT programmer.
An implementation that did "multiple event cycles" would probably not break
client code but would still be strictly wrong.  So, imagine me shouting at you
in the next office - ONE EVENT!

You stated that it was unclear what the return value of readAndDispatch was.
I clarified.

If you can't code an event loop, we could add one to Display as follows:

void eventLoop () {
        while (true) {
                if (!readAndDispatch ()) sleep ();
        }
}

The disadvantage to this kind of helper method (other than increasing code
bulk) is that it is useless.  A real app needs a termination condition.  A real
app needs a way to wait for the result of a dialog before continuing.  It would
be possible to define and interface (IKeepRunning) or and a method to
Display (Display.quitLoop (boolean quit)) that exited the loop but then we'd
have to stack the quit values so that multiple nested loops exited properly.
Why would we do all this when it's just as easy to code the loop?  Why have
our own invented schemes that we need to debug, maintain, optimize and
also - the most important one - port?  Each operating system has the concept
of an event loop so we expose it in as thin a manner possible and we are done.
There are enough real problems implementing SWT on different platforms so
why invent more?  I think this covers your discussion of "coroutines" which
could never be implemented unless we had complete control over threading
and access to the private state of the operating system - this is never happening.

Also, I repeat "sendEvent" and "postEvent" are implementation details of SWT.
Not sure why anyone should care about them.  We were considering punting
"postEvent" because it was an artifact from the old days.  I'm not sure there is
any reason for it today, other than it gives us a way to reorder events - but again,
this is all private SWT implementation stuff, if we need to reorder events, there
are other ways to do it..  No SWT client cares about "send" versus "post".

Please submit sample code that shows "stale data" tree thing so we can fix the
bug or document the behavior.  That's way more useful that a philosophical
discussion about event orderings.

So, Jeff Skywalker don't fall for the Dark Side.  Not sure if I'm Darth Vader?

"Jeff Brown" <j9brown@xxxxxxxxxxxxxxxxx> Sent by: platform-swt-dev-admin@xxxxxxxxxxx 11/27/01 01:58 AM Please respond to platform-swt-dev

To:        <platform-swt-dev@xxxxxxxxxxx>         cc:                 Subject:        Re: [platform-swt-dev] MacOS X port status?

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.

_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev