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

[Steve Northover <Steve_Northover@xxxxxxxxxx>]

Is Fox happy when only one thread is
in the library or must it be only the UI thread?  Windows insists
that the UI thread is the only thread that can make widget calls but allows
other threads to make graphics calls.  X/Motif and GTK allow only
one thread in the library but doesn't care which.  If Fox is the same
(likely because it is build on X), then you should sychronize OS just like
X/Motif and GTK.  Don't bother synchronizing the methods in GC/Image
unless they access global state.  SWT graphics is "thread aware"
but not "thread safe".  This means that multiple thread
in a single GC is an error but there can be multiple threads, each with
their own GC.

The code is commented out for now because
of a particular usage pattern in Eclipse that dies.  We are working
on a fix.  You should use a copy of the commented out code.

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

03/17/2004 10:47 AM

Please respond to
platform-swt-dev

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

Steve,
 
I've checked the XInitThreads-related problems and the
OS code in swt-motif and swt-gtk.
All I can say for the moment is that the situation sucks.
 
I either have to make all my OS methods synchronized,
 
or I have to stick with XInitThreads and hope that aside
from X printing & Japanese input (I don't care for these), there are
no other issues with this method. 
+ should synchronize some methods in Fox's GC/Image classes
which change state.
 
Can you tell me why the code in swt-motif/Display.sleep()
which uses select() is commented and instead wait(50) is used (which may
incur small lag in processing new events)? The comment just says that the
select() based code is intentionally commented. 
Code similar to the commented select() is used internally
in Fox for waiting X & other events.
 
 
If only calls into SWT GC/Image etc. followed the single-thread
rules for the SWT widgets.. 
  
Anyway, many thanks for your support.
 
Regards,
Ivan
 
----- Original Message ----- 
From: Steve
Northover 
To: platform-swt-dev@xxxxxxxxxxx

Sent: Wednesday, March 17, 2004 4:50 PM
Subject: Re: [platform-swt-dev] Xlib: unexpected
async reply (sequence 0xHEX)!


Yes.  Eclipse uses every feature ...

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

03/17/2004 09:34 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.  
Sorry. I've just realized the meaning of this. Are you saying, that in
SWT it is OK to call org.eclipse.swt.graphics.GC/Image/Font methods from
any thread? Does Eclipse use this feature? 
  
I've just checked - and there are no thread check calls in the methods
of these classes. If so, I'll have to check if Fox allows this.
  
Regards, 
Ivan