I attached a full trace off the the program running, can anyone check it out for me?
2011/3/5 Chris Vine <ch...@cvine.freeserve.co.uk> > On Sat, 5 Mar 2011 11:58:23 +0800 > Wei-Ning Huang <aitjc...@gmail.com> wrote: > [snip] > > From what I can see, the program is stuck because the main thread > > locked a mutex in #3. > > But from the backtrace, the mutex seems to be locked by > > gtk_main_loop_run() which is something I can't control, > > and somehow it locked the same mutex as gdk_threads_enter()? any > > ideas? > > If it isn't recursion then somewhere in your '....' you probably have > out-of-order locking. > > I should start by making the gdk global lock 'Lock 1' and work from > there. In other words, don't call gdk_threads_enter() when you are > holding a lock of your own. Also, don't call gdk_threads_enter() in a > GTK+ signal handler because it will already be locked there. (But that > is not true of ordinary glib main loop events.) > > Best of all, don't use the global lock at all but instead invoke > callbacks in the main loop with g_idle_add(). This is a cleaner > design and also has the benefit of making your program portable to > windows and other non-X11 platforms. > > Chris > > > -- AZ Huang <http://berelent.blogspot.com/>
_______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
