[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-swt-dev] Xlib: unexpected async reply ( sequence0xHEX)!

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.
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.

Sent by: platform-swt-dev-admin@xxxxxxxxxxx

03/19/2004 06:44 AM

Please respond to

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.



platform-swt-dev mailing list