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 -----
Sent: Wednesday, March 17, 2004 4:50
PM
Subject: Re: [platform-swt-dev] Xlib:
unexpected async reply (sequence 0xHEX)!
Yes. Eclipse uses every
feature ...
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
|