Re: [gtk-list] thread safety broken? (and Changes-1.2.txt)
- From: Sebastian Wilhelmi <wilhelmi ira uka de>
- To: gtk-list redhat com, "Charles 'Buck' Krasic" <krasic cse ogi edu>
- Subject: Re: [gtk-list] thread safety broken? (and Changes-1.2.txt)
- Date: Mon, 01 Feb 1999 10:07:02 +0100
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 |
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]