Re: strange deadlock ...

[Owen Taylor <otaylor redhat com>]

Michael Meeks <michael ximian com> writes:

> Hi Havoc,
> 
> On 17 Jul 2001, Havoc Pennington wrote:
> > Michael Meeks <michael ximian com> writes: 
> > > 	The thing is - that this is not a multi-threaded program, it is
> > > merely a single thread. Simply run libbonoboui/tests/test-selector[1] and
> > > click 'get Id' and hey presto.
> > 
> > Right, but someone is calling g_thread_init() so locking is still
> > done. (There's no way to say "if (> 1 thread exists)")
> 
> 	I appreciate that :-) the thing is, that this is not some whacked
> out, unusual race condition - caused by some obscure use of threading, 
> that will not affect anyone.
> 
> 	On the contrary, it will cripple anyone using threads and Gtk+ eg.
> try adding a g_thread_init to gtk-demo, and then pressing "Dialog and
> Message Boxes" and then any button [ to cause a re-entering of the glib
> mainloop through gtk_dialog_run ].
> 
> 	Bang, deadlock.

But this is just a bug in gtk_dialog_run. gtk_dialog_run()
knows that if g_thread_init() has called an the application
isn't buggy, that it holds the GTK+ lock, so it should do:

  ri.loop = g_main_new (FALSE);

+  GDK_THREADS_LEAVE ()

  g_main_loop_run (ri.loop);

-  GDK_THREADS_ENTER ()

  g_main_loop_unref (ri.loop);

The problem is that in the case of Bonobo usage, you
have know idea whether the GDK lock is held or not.

Regards,
                                        Owen