[albireo-dev] single event thread - experience with AWT->SWT approach

[Bruno Haible <haible@xxxxxxx>]

Hi Gordon et al.,

Let me explain the experience I got with the AWT->SWT approach of
the "single event thread" implementation.

This approach was inspired by the constraint to not modify the AWT source
code and to not modify the SWT source code.

It activates a subclass of java.awt.EventQueue that can handle events as
follows:
  1) It can execute the event in the same thread (the AWT thread),
     without interacting with the SWT thread.
  2) It can execute the event in the same thread (the AWT thread),
     and block the SWT thread during this processing (in a state where
     it does not hold any user-visible locks).
  3) It can execute the event in the SWT thread, and block the AWT thread
     during this processing (in a state where it does not hold any user-visible
     locks).
  4) It can execute the event in the SWT thread, asynchronously.

In the code, it's this:
  1) superDispatchEvent(event);
  2) blockingUnredirectedDispatchEvent(event);
  3) IlvSWTUtil.syncExec(_display, delayedDispatchTask(event, false));
  4) IlvSWTUtil.asyncExec(_display, delayedDispatchTask(event, true));

The handling of an event has a heuristic for determining which of the 4
approaches to use. For most events, #3 is used: user code can access the
SWT Display, hence it must be done in the SWT thread, but to avoid deadlocks
due to the AWT/Swing tree lock, the AWT thread must be blocked in a state
where it cannot accept new events.

The heuristic is currently hardcoded, but ought to be customizable if we end
up using this approach in Albireo.

The three biggest problems come from hardcoded behaviour in AWT:

  * The AWT uses the method EventQueue.isDispatchThread() in some locations,
    and it's hardcoded to return false in the cases 3) and 4).
  * The class Dialog calls EventDispatchThread.pumpEventsForHierarchy
    which calls EventQueue.getNextEvent(int) which blocks without looking
    for events at other event sources - all package access, without
    a way to override the behaviour.
  * During focus handling and drag&drop handling, the dispatch of events
    of type SentEvent and SequencedEvent (in the java.awt package) is
    not customizable; there is not even a way to inspect the "nested"
    event inside such an event.

These three problems are the reason for most of the limitations.

Bruno