Thanks Steve,
The offending code in Eclipse seems to be the stuff that draws
the small orange progress indicator, which appeared in Fox 3.0 Msomething. It is
drawn from a background thread. There maybe others, I don't know.
I did synchronize most of the methods in Fox's OS class
and this fixed the issue.
Well, Fox is going to need a patch where callbacks need
to be plugged around its blocking select() statement which is burried
deeply inside Fox's message processing, in order to give the background thread
more chances to draw.
Regards,
Ivan
P.S. It seems Fox on X11 doesn't enforce the UI thread but
follows the GTK+/Motif policy: only one, but anyone thread at any time may be in
Fox. The patch around the select() call is needed, though.
----- Original Message -----
Sent: Thursday, March 18, 2004 3:45
PM
Subject: Re: [platform-swt-dev] Xlib:
unexpected async reply ( sequence0xHEX)!
Only global state needs to be
protected. If your implementation or Fox has global state, then you need
to lock. If it persists between calls, then it seems that you must call
everything from the UI thread. In that case, graphics calls that are not
done from the UI thread will need to be the asyncExec'd there. If Fox
doesn't enforce the UI thread rule and you ignore it, then you are at risk of
crashing unexpectedly. You should check with the Fox designer and get
their opinion before proceeding.
ivan.markov@xxxxxxxxx Sent by: platform-swt-dev-admin@xxxxxxxxxxx
03/19/2004 06:44 AM
Please respond
to platform-swt-dev |
|
To
| platform-swt-dev@xxxxxxxxxxx
|
cc
|
|
Subject
| Re: [platform-swt-dev]
Xlib: unexpected async reply
(sequence0xHEX)! |
|
> Is Fox happy when only one thread is in the library or must it
be only the > UI thread?
Unfortunately, by Fox spec it should be
the UI thread only. However, IMO it is unrealistically strong restriction.
In reality I believe it is OK for another thread to be in the library, as
long as there is no other thread there, exactly as you say below.
Fortunately, Fox does not enforce programatically the rule
only-UI-thread-may-call-into-it, like SWT widgets do.
> Windows
insists that the UI thread is the only thread that can > make widget
calls but allows other threads to make graphics calls.
You can make
widget calls (i.e. to HWND functions) from any thread, but you risk
deadlocking as the call is internally delegated to the UI thread where the
HWND is created; so yes - calling widget functions from another thread is
somewhat risky on Win32. HDC calls are OK.
> 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.
Exactly. Although Fox
places stronger restrictions (only the UI thread in the library), I don't
see anything preventing another thread calling into the library, as long as
no race conditions occur.
I would need to synchronize _only_ specific
_Fox_ GC/Image calls if I take the other approach (XInitThreads + allowing
several threads in the library), because some methods in Fox GC/Image
classes are not thread save, as they change Fox library state
non-atomically. There may be others - haven't checked yet. In general -
this approach seems risky to me as I may miss some Fox method call that
needs synchronizing.
> > 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.
Thanks.
Regards, Ivan
_______________________________________________ platform-swt-dev
mailing
list platform-swt-dev@xxxxxxxxxxx http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
|