Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [albireo-dev] single event thread - approaches 
Bruno Haible wrote:

Hi Gordon et al.,

Let me try to list all possible ways to fix the "two event threads" problem
that one can think of.

Recall that:

In AWT, the construction of an EventQueue object creates a thread, called
the AWT-EventQueue-n thread. These event queues can be chained, like a stack.
When you have the chain
  AWT-EventQueue-0 -> AWT-EventQueue-1 -> ... -> AWT-EventQueue-n
the events will be handled in the last thread of the chain: AWT-EventQueue-n.
Swing calls (more precisely, anything that touches the AWT/Swing tree lock)
must be executed in the currently active AWT-EventQueue thread, otherwise a
deadlock may occur.

In SWT, the thread that creates a Display becomes the thread associated to
this Display. All API calls to the Display must be performed in this thread,
otherwise an exception is thrown (strict verification).

Possible approaches:

1) The AWT->SWT approach. Most AWT events are retargeted from the AWT thread
   to the SWT thread and executed there. This has been done in the
   IlvEventThreadUtil class. The result is workable with many limitations.
   Too many limitations, in my feeling.
Because one of the limitations prevents the use of AWT dialogs, I personally wouldn't be able to take advantage of this approach in most cases. But perhaps others would? That would be interesting to know. (Of course, the big benefit would be that there would be much less hopping from thread to thread.) 



2) The SWT->AWT approach. Most SWT events are retargeted from the SWT to the
   AWT thread and executed there. SWT's thread modification is modified.
I didn't understand that last sentence :-). Did you mean SWT's thread *checking* is modified? This might be more promising than #1 because it's more likely that we can convince the SWT developers to make any changes necessary to enable it. 



3) The real single-thread approach. The default Display is created from
   within the AWT thread, and serves both the AWT event queue as well as the
   SWT event queue.
This may be worth further exploration. I imagine it might have some of the same problems as above with respect to modal dialogs? Any place where a "special" event handling loop is hardcoded would be a danger. 



4) Create an implementation of AWT on top of SWT.

5) Create an implementation of SWT on top of AWT. This has been done by
   the SWTSwing and SwingWT projects on sourceforge.net.

#4 is too much work in my opinion.
Isn't SwingWT an example of #4, not #5? In any case I agree that this is hard to get exactly right. 



I don't see other approaches: As long as AWT and SWT rely on different
primitives at the C level, events coming from the windowing system are
dispatched in different paths depending to which kind of window they apply
(window created by AWT or created by SWT):

                    /---> AWT event queue
                   /
    system event --
                   \
                    \---> SWT event queue

Other thoughts?

Bruno
_______________________________________________
albireo-dev mailing list
albireo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/albireo-dev

Back to the top