I believe sgtk_init_threads is being called too late to influence
gdk_threads_enter and gdk_threads_leave, and that instead they're
ending up as noops.

The program threads.scm below illustrates the problem, threads 1, 2
and 3 are able to "enter" all at the same time.  I've using a recent
i386 debian with the guile cvs and pthreads for this,

	1 entering
	1 entered
	2 entering
	2 entered
	3 entering
	3 entered
	...

Adding a printf of gdk_threads_mutex to the generated
sgtk_gdk_threads_enter reveals NULL.  I'm pretty sure gtk_init has
called gdk_init which has initialized it's threading before
sgtk_init_threads has had a chance to setup the glib level stuff.

I get some joy from moving the sgtk_init_threads call from
sgtk_init_substrate to the start of sgtk_init_with_args (before
gtk_init).  This exposes however that gdk-threads-enter shouldn't be
using SCM_DEFER_INTS, since of course it needs other threads to run to
release the mutex.

        * gdk-1.2.defs (gdk_threads_enter, gdk_threads_leave): Add undeferred,
        since these are thread safe, and in particular enter needs other
        threads runnable to release the mutex.
        * guile-gtk.c (sgtk_init_substrate): Move sgtk_init_threads ....
        (sgtk_init_with_args): ... to here, to ensure glib threading is setup
        before gtk_init and gdk_init run.

It might be nice if the glib level inits were separated, for clarity.
Perhaps that can wait until there's an actual glib module though.