Re: gtk + threads

On Mon, Jan 31, 2005 at 10:44:53AM +0100, Felix Kater wrote:
Hi Muthu,

X window system calls must be made from only
one thread. Making X calls from two threads
will cause a crash.
This is wrong. Xlib is itself thread agnostic. Xlib has no
thread local state. According to X docs (XInitThreads), as long as all
calls to Xlib are serialized, you can call X from any thread, it doesn't
care. The XInitThreads and XLock are simply one option to provide
locking if you have no other. If you provide your own lock, then you
don't even need to call XInitThreads.

I think you must set the gtk_* calls from the
idle_function alone. Thatis , it must be a
part of the main loop that works the GUI.
This is a recommended pattern, but not a technical requirement.

May I ask you again what's the essetial point about the
single-thread-strategy handling gtk:

(a) Is it the fact that there will never be more than one access to gtk
at the same time -- or

(b) something else I did not get (e.g. must be *one* thread etc)?

In case of (a): Shouldn't it be enough then to lock all access to gtk by
the same mutex/lock which could then be spread over different functions
and threads then?
Exactly. There is a single lock for GDK and GTK. It's documented in the
GDK manual on the chapter about threading.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]