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 _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
