On Mon, Apr 04, 2005 at 06:44:10PM +0200, Oliver Lemke wrote: > On Mon, 2005-04-04 at 20:09 +1000, Jonathan Matthew wrote: > > I've been experiencing a lot of deadlocks when using rhythmbox-applet, > > which turned out to be caused by recursive GDK_THREADS_ENTER calls. > > > > This was happening on gconf calls, which caused ORBit to process any > > incoming requests *within the gconf call*. If the gconf call was made > > with the gdk lock held, and there was a bonobo remote request waiting, > > the bonobo request handler would try to take the gdk lock again. > > > > Dropping the gdk lock before anything that could result in a gconf > > call looked way too hard, so I just hacked in gdk lock/unlock functions > > using a GStaticRecMutex instead of the GMutex the standard functions > > use. This is patch-6 and patch-7 in my rhythmbox--remote--0.9 branch. > > After looking at your code (and reading the gdk threads docs) I'm a bit > confused. Is it not necessary to call gdk_threads_init after > gdk_threads_set_lock_functions in your rb_threads_init function?
In theory, yes, but all gdk_threads_init does is set up the default locking functions. It does appear to be harmless, so I'll add a gdk_threads_init call to rb_threads_init just in case. > For sure you know this stuff better than me, but the docs say that every > process that wants to use threads has to call gdk_threads_init before > entering the gtk main loop. Moreover, it's written that g_thread_init > must be called before this function. Where is this done in rb? I had to use gdb to find this out, but gnome_program_init calls g_thread_init. -jonathan _______________________________________________ rhythmbox-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/rhythmbox-devel
