#124 E vs Swing scheduling conflicts

[Steve Jenson]

FIXED
Generally, code in an E vat deals with outside
"devices" provided by the Java API (like java.io.File)
under the assumption that they are themselves
thread-safe, since that's the normal Java style.
Therefore, we generally assume we can make non-blocking
synchronous calls to them safely from a vat thread.

Unfortunately, as explained at
http://java.sun.com/docs/books/tutorial/uiswing/overview/threads.html
, Swing totally violates that assumption. Instead,
swing has its own AWT-Event thread servicing its own
queue, in a very vat like fashion. Few methods on Swing
objects are thread safe, and the discipline required to
call them safely from other threads (invokeNow,
invokeLater) is too onerous to impose on all E code. At
the same time, E code needs to implement interfaces of
objects held by Swing objects, where those Swing
objects will be invoking those interfaces in the
AWT-Event thread. The "solution" up through 0.8.9* was
to use EventualDeflector, but this doesn't really work.

Followups
2001-Sep-15 18:57 markm
Thanks to Dean, this is now fixed by having "fe"
(front-end) vats live in the AWT-event thread and use
the AWT-event queue. Immediate vs Eventual Deflectors
have gone away, rather we now only have Deflectors
(which have become concrete). The AWT-event queue is a
too complex mechanism, with three priority levels and a
stack of queues (the stack is for modal dialog boxes,
which raises an issue to be filed in a separate bug
report). The lowest priority is for paint/update
events. In order for fe-vat turns not to indefinitely
postpone paint/update events, we schedule them at this
lowest priority, despite the lack of support for this
in the Java API. We do so by wrapping these turns in a
fake paint event, the
org.erights.e.elib.prim.FERunnerEvent.