This kind of error is almost certainly caused by multiple
threads in Xlib. Graphics operation can happen from any thread. It
is only widget operations that need to execute in the UI thread. SWT/Fox
needs to deal with this hopefully using the "Fox threading story" (whatever that
is). In the past, we tried to use Xlib's XInitThreads() for the X/Motif
port but this caused hangs in other components (Printing, Input Method Editor)
because the locks were not re-entrant. There were other reasons that
XInitThreads() could not be used that escape me but could probably be found by
searching Bugzilla.
Thanks, I'll search for XInitThreads() in the
bugbase.
The "Fox threading story" is like the "SWT threading story" in
that you can call into UI components only from the thread that spins the message
loop.
Fox is further restricted in that there can be only one UI
thread in the application (the loop is spinned in the application object which
is holded in a static var, referenced everywhere).
Does Eclipse 3.0, by any chance, try to create more than one
Display instance (in different threads)?
More than one UI thread (ala SWT/Win32) is not
supported in SWT/Fox, but I can't recall at the moment what happens if the
user tries to do so.
Note: Stuff like Display.executySync,
display.executeAsync, Display.wake, Display.sleep etc. is already correctly
implemented in SWT/Fox so it is not some major rule I've failed to notice - it
runs Eclipse 2.X after all!
Regards,
Ivan
|