Re: [platform-swt-dev] Xlib: unexpected async reply (sequence 0xHEX)!

[Steve Northover <Steve_Northover@xxxxxxxxxx>]

Mulitple Displays are not used by Eclipse
because they are not supported on all platforms.  On X/Motif, due
to the problems with XInitThreads(), we used Java locking. This was achieved
by synchronizing almost all of the methods in the class OS.  The methods
that were not synchronized involved sleeping.  Go check the code.

"Ivan Markov" <ivan.markov@xxxxxxxxx>
Sent by: platform-swt-dev-admin@xxxxxxxxxxx

03/17/2004 09:24 AM

Please respond to
platform-swt-dev

To	platform-swt-dev@xxxxxxxxxxx
cc
Subject	Re: [platform-swt-dev] Xlib: unexpected async reply (sequence 0xHEX)!

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