Re: multi-threaded apps with GTK

[Chris Vine <chris cvine freeserve co uk>]

On Thursday 09 February 2006 20:56, mikecorn t-online de wrote:
> I am now making good progress, thanks to the advice I got in this forum.
> Many thanks to all those who chipped in, even though I got emotional
> from my frustrations.
>
> I complained 1-2 weeks ago that GTK does not work out of the box for
> multi-threaded apps, and asked, why not? A complex and poorly documented
> burden is placed on the programmer using GTK, IMO.
>
> One of the answers I got was that the overhead of locking shared
> resorces should not be borne by apps that do not need this. I responded
> that locking takes nanoseconds (as long as the resource is not already
> locked from another thread). Someone asked me if I knew what I was
> talking about. Today I took the time to write a benchmark. I am not sure
> this is the right benchmark for this issue, but here are the results.

The main problem is not overhead, but with having hidden global locking in GUI 
toolkits in the first place.  This very easily results in deadlocks from 
out-of-order locking with other mutexes employed by the user.

Qt adopts exactly the same approach as GTK+.  Events either have to be posted 
as messages to the event loop thread from other threads, or if window system 
functions are invoked directly from a thread other than the Qt event loop 
thread, then the global Qt lock must be explicitly invoked by the user (and 
the user is accordingly responsible for avoiding deadlocks, which is 
something you did not manage).

When I last looked at it, Windows only allows the posting of events and no 
direct invocation of window functions from multiple threads.

Glib has GAsyncQueue for message passing between threads.  Other approaches 
often used are to pass events by using a GIOChannel object (or some other 
GSource object) and a pipe, which is more closely analogous to the Windows 
and Qt approaches.  For an example of this see

http://cvs.sourceforge.net/viewcvs.py/efax-gtk/efax-gtk/src/utils/notifier.h?rev=1.10
and
http://cvs.sourceforge.net/viewcvs.py/efax-gtk/efax-gtk/src/utils/notifier.cpp?rev=1.8

The "burden on the programmer" is not "poorly documented" - the FAQ on this 
was given to you earlier and the example given is very similar to the example 
given, for example, in the Qt documentation pages.  And it is no more complex 
than it has to be, or than other comparable toolkits are.

Chris