Re: [gtk-list] thread safety broken? (and Changes-1.2.txt)

[Sebastian Wilhelmi <wilhelmi ira uka de>]

Hi, Charles

> I'm working on a multithreaded application, an mpeg video player, that
> I've been migrating to gtk for some time now.
> 
> About four or five months ago, I started out with gtk 1.0.  I'm not an
> experienced X programmer, so when I started getting dreaded 'Xlib:
> async reply error', I rapidly retreated to the most conservative
> approach that various faqs, newsgroup postings, etc. described: I put
> all gui activity into a single thread, and I had other threads use
> that thread as an intermediary for any gui work.  This was reliable,
> but added a lot of ugliness to my code.
> 
> A few weeks ago, I read something that indicated the 1.1 series was
> incorporating better thread support.  Then I read Changes-1.2.txt.  I
> thought "great! this will let me really clean up my code".  So I
> proceeded to try and move to 1.1 with threads.
> 
> My experience so far has not been good.  I desperately wanted to make
> this work.  I spent a lot of time pulling my hair out searching
> mailing mailing list archives, FAQs, source, etc.  I've been stubborn
> about reverting back to my 1.0 model because it's truly a pain in the
> butt.  .
> 
> I often got deadlocks because the glib main loop lock and the gdk
> global mutex were not acquired in the same order.  I've concluded for
> now that thread safety in gtk+ simply isn't there yet.
> 
> I found out about XThreadsInit, which seems to work well in covering
> the XAsyncReply problems.
> 
> For internal thread safety of gtk+/gdk/glib, I resort to using a mutex
> to guard all access to gtk+/gdk/glib, and having only a single thread
> invoke gtk_main.
> 
> I do *not* call g_thread_init(), because doing so means that gtk+ will
> deadlock even if I protect all my gui access with a mutex.  (This is
> because interaction between gtk_main, which accesses the gdk and glib
> mutex, and whatever gtk function my other threads might happen to
> run).  By not calling g_thread_init(), the gdk mutex is not activated.
> So far I'm OK, although I expect there are still nasty races between
> the thread that invokes gtk_main and the rest.
> 
> I'm curious about whether I've made a mistake in drawing these
> conclusions.  If not, I'd suggest amending Changes-1.2.txt with a
> warning to prevent other newbies from wasting time in finding out the
> same kind of stuff.
> 
> I also noticed the following errors in the Changes-1.2.txt:
> 
> >   - You must call g_thread_init(), then gtk_thread_init()
> >     in a threaded GTK+ program.
> 
> gtk_thread_init doesn't exist anymore, right?  It looks like gdk_init
> (invoked by gtk_init) automatically detects threads when g_thread_init
> has been called first.
> 
> >   - Idles, timeouts, and input functions are executed outside
> >     of the main GTK+ lock. So, if you need to call GTK+
> >     inside of such a callback, you must surround the callback
> >    with a gtk_thread_enter()/gtk_thread_leave() pair.
> 
> It's gdk_thread_enter() and gdk_thread_leave(), right?
> 
> >      b) Link with the libraries returned by:
> >
> >           gtk-config --libs gthread
> 
> 
> My gtk-config (from 1.1.11-1.1.13) doesn't understand anything about
> gthread, although glib-config does.
> 
> Also, given the above observations, I tried to use testthreads.c and
> found that it confirmed that gtk and threads are broken.

I can only comment on the glib part, but I'm sure Owen can answer the gtk+
related things pointed out:

The MT stuff still is quite new and not tested very well either, so we
would really appreciate your further commitment to helping us debug this.
A first step would be to compile glib, gtk+ and your program with the
additional compile flag -DG_DEBUG_LOCKS, e.g. do 

make CFLAGS+=-DG_DEBUG_LOCKS

That should help you find the deadlocks and then you can report them to
us. (Warning: This will throw huge amounts of output at you). And don't
forget: You have to call g_thread_init (NULL), otherwise no MT protection
is done in glib, that means you can't even rely on calling glib functions
in different threads (That holds even true for g_new and friends)

Bye,
Sebastian

-- 
Sebastian Wilhelmi                   |            här ovanför alla molnen
mailto:wilhelmi@ira.uka.de           |      är himmlen så förunerligt blå
http://goethe.ira.uka.de/~wilhelmi   |