Re: gdk_threads_leave in gtk callback ?

[Vladimir <kv11111 mail ru>]

Thanks a lot for comprehensive explanations.

There are two uses of GTK+ in non-main threads:
1. error reporting via message boxes and 
2. adding text (which comes from network) to GUI windows.

I can do both of it in main thread but this involves copying text to
dynamically allocated buffers.

BTW, can I use g_idle_add in non-main thread without locking ?

Gus Koppel wrote:

> Vladimir wrote:
>
> > I'm writing program with several threads each of which uses gtk.
> > I need to wait for one of the threads in gtk-generated callback. I can't
> > do it directly because of gdk lock. So the question is: can I temporarily
> > release gdk lock in gtk-generated callback ? Will it cause any problems ?
>
> You should know that accessing GDK / GTK+ functions from different
> threads is bad programming practice, because GTK+ is not thread-safe.
> Trying to compensate this properly on application side (using
> gdk_threads_enter() + gdk_threads_leave() ) would result in quite some
> code overhead, likely some performance penalty and is error-prone.
>
> Even worse sounds the idea of "waiting for something" inside a GTK+
> callback. They are supposed to finish as quickly as possible. Everything
> else sounds like great potential for deadlocks.
>
> So the answer is: no. Even if your app doesn't crash immediately, it may
> do so sometime later in arbitrary states, possibly leaving you with no
> trace where to search for the cause of the crash.
>
> Generally, the better way would likely be, to set a global flag when the
> thread you want to wait for, finishes. A GTK+ handler must not wait for
> this, but rather be able to deal with both situations appropriately:
> either the other thread hasn't finished yet, then exit immediately. If
> the other thread has finished, then do what you originally wanted to.
>
> If your handler is not supposed to be executed at all before the other
> thread has finished, then you should prevent the handler to be called,
> rather than attempting to wait within the handler until the other thread
> finishes. You know, there are multiple options for preventing handlers
> to be executed.
>
> You're free to use multiple threads for arbitrary computations within
> your program. But you really should not access GTK+ / GDK from within
> each of them. It makes programming more complicated and error-prone and
> the graphics output a bit slower (due to all the thread locks that need
> to be provided). Leaving all the GDK / GTK+ stuff to just one thread
> would definitely be the better idea. Since you started with programming
> multiple threads you should also know how to signal a central GTK+ / GDK
> thread what to do from other threads, don't you?

-- 
             Vladimir