Re: [gtk-list] Re: XInitThreads causing problems to GTK windows.

[Olaf Klischat <olaf klischat tu-clausthal de>]

Sebastian Wilhelmi wrote:
> 
> Hi, Peter
> 
> > PS.: It is however possible, that the use of XThreadsInit() exposes a bug in
> > GTK+, so I'll have a look at your prog anyway.
> 
> I have looked at your prog. It looks like the problem is in X, but who knows.
> Just don't use XInitThreads(), as it will slow down things additionally and
> gtk already takes care of that. But you have to call g_thread_init() before
> the call to gtk_init(). And then you have to call gdk_thread_enter() before
> any call to gtk/gdk-function and gdk_thread_leave() afterwards; not within

Is that necessary even if I don't call gtk functions from anywhere
_except_ the main thread?

Is it possible to establish a communication link between the main thread
and some separate 'worker thread' based on (X- ?) Events? So, every time
the worker thread wants to GUI to be updated somehow, it might post a
message into the main thread's message queue (does each thread have a
separate message queue, like in Win32? I don't think so..). At some
later time, the main thread reads that message and performs the required
GUI work.
How could this be done?

> signals, as they already hold the lock but also before gtk_main() and friends.

A silly question: What do you mean by 'signals'? GTK signal handlers? Or
something that has to do with Unix process signals? I'm not yet very
familiar with unix programming, so excuse my lack of knowledge...

Olaf