There's a nasty race condition which can result in a deadlock in GTK+
1.1.9, and the current CVS tree.  glib-rao-981218-0.patch has been
made against the current GLIB cvs tree.

The following scenario results in a deadlock.  Time goes down.

  thread1             gtk_main / g_main event loop thread
  -------             -----------------------------------
|                     unlock main_loop
| lock gdk mutex
|                     poll_func
|                     lock main_loop
|                     call prepare or check funcs in gdkevents.c
|                     wait for lock on gdk mutex
| g_source_add call,
| results in
| a wait for main_loop
|
v
time

So you have thread1 holding the gdk lock and waiting on the main_loop
lock.  The g_main event loop thread is holding the main_loop lock and
waiting for the gdk lock.  Deadlock ensues.

Since commonly called functions such as gtk_widget_queue_draw result
in a call back to the g_main event loop, in any non-trivial threaded
GTK+ program, deadlock generally occurs before the end of normal
program execution.

The solution to the problem is to unlock the main_loop mutex before
all SourceFuncs calls and then lock the main_loop mutex back.
glib-rao-981218-0.patch does this.  Currently, only dispatch calls
result in an unlock/lock of the main_loop mutex.

ChangeLog entry:

1998-12-18  Paul Fisher  <rao@gnu.org>

	* gmain.c: Unlock and lock main_loop mutex around all GSourceFuncs
	calls, not just dispatch calls.