gdk_threads_enter/leave in 2.6

[Michael Meeks <michael ximian com>]

Hi guys,

	So - I'm currently trying (with some limited success) to weld together
the OO.o(VCL) and gtk+ mainloops. This creates some interesting
problems.

	The nastiest problem is that while I can try and create a new
SolarMutex (VCL's Yield/X/big-global lock) by wrapping the
gdk_threads_mutex, problems arise since the VCL mutex is a recursive
one, and the gdk mutex is not.

	In many cases this is not so much of a problem; since we  drop the
recursive mutex when we're about to call g_main_iteration,
but picking it up again when we know the gdk_ lock is already held - in
X filter methods etc. is not overly elegant. Some of the mess that this
creates can be see here:

	http://ooo.ximian.com/patches/RC3/gtk-integration.diff
and	http://ooo.ximian.com/patches/RC3/glib-integration.diff

	[ the salinst.cxx code being the main issue ].

	So - in an ideal world I'd be able to hook gdk_threads_enter/leave and
re-direct these into my code which would then be able to do a good job
of this with a single unified locking scheme that provides both expected
behaviors.

	There are two stumbling blocks to this approach:

	* GDK_THREADS_ENTER/LEAVE - these in-line macros code
	  the assumption that we have a GMutex * to call 
	  g_mutex_[un]lock on into all user code.

	* gdk_threads_enter/leave are not hookable.

	So; assuming I hit some insuperable obstacle with my current
machinations [ which seems likely ] the only real solution at my
disposal is pure evil: provide a replacement gthread method table, and
special case g_mutex_lock (lock == gdk_threads_mutex) - a rather
undesirable solution.

	Alternatively, we could (perhaps) fix this up in gtk+ like this. If
this is interesting to people, I'd be most happy to hack it up
forthwith:

	+ typedef void (*GdkLockUnlockFn) (void);
	+ extern GdkLockUnlockFn gdk_threads_lock;
	+ extern GdkLockUnlockFn gdk_threads_unlock;

#define GDK_THREADS_ENTER() \
	if (gdk_threads_lock) \
		gdk_threads_unlock ();
...

	where gdk_threads_lock/unlock point at enter/leave in threaded mode,
but NULL in non-threaded mode.

	In the non-threaded case we loose nothing, and in the threaded case, we
get an extra stack frame of gdk_threads_enter -> g_thread_lock; and
perhaps an extra check in gdk_threads_enter/leave.

	How does that sound ? Are there other alternatives ? being able to hook
these would be really helpful to me.

	Thanks,

		Michael.

-- 
 michael ximian com  <><, Pseudo Engineer, itinerant idiot