Hi Chris, Thanks for your great help!!!
I finally find out why the deadlock always occurs after 5 minutes. My applications has a function the autosave the document every X minute, and I use the g_timeout_add_seconds with callback to handle it. However the callback contains a line 'while (gtk_events_pending()) gtk_main_iteration()'. That is the reason why the deadlock occurs!!! I remove the line and the deadlock is gone! Big thanks for your help, learned a lot from your reply :) Best regards, Wei-Ning Huang 2011/3/7 Chris Vine <ch...@cvine.freeserve.co.uk> > On Sun, 6 Mar 2011 16:03:43 +0000 > Chris Vine <ch...@cvine.freeserve.co.uk> wrote: > > On Sun, 6 Mar 2011 10:57:24 +0800 > > Wei-Ning Huang <aitjc...@gmail.com> wrote: > [snip] > > > I'm starting to think it's the bug of gtk+, or perhaps the > kernel? > > > btw, I'm using Arch Linux with Kernel 2.6.37(autogroup patched), > > > Gtk+ 2.22. > > > > > > SI once suspect that it maybe something to do with the autogroup > > > patch I'm using, so I switch to the > > > default 2.6.37 kernel. The result is the same.. still deadlocks. > > > > > > frustrated ... (but glad that this didn't happen on ubuntu) > > > > In theory it could be a bug in glib, gtk+ or the kernel. If, say, > > your motion_compile_thread() function is the only function executed > > by the test thread and never acquires any other locks than your test > > mutex, and you do not have a livelock, then I think you are right to > > be worried about that. Otherwise, it is more likely to be a bug in > > your code, and the fact that it works on ubuntu is not particularly > > indicative of anything, since this may just be the result of timing > > differences or different scheduling policies. > > By the way, your first code did not treat the gdk global lock as 'Lock > 1' and you did not indicate in your latest e-mail whether you have > corrected that: I should not even think about a glib/gtk+/kernel bug > until you have done so. > > To take an example, if your test thread is started from a gtk+ signal > handler, the thread will be started holding the gdk global lock, and > therefore your 'while' loop will acquire 'cp_mutex' holding that lock. > If another thread calls gdk_threads_enter() while holding cp_mutex, you > are in line for a deadlock just from that. > > 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
