Re: Gtkhtml on win32, it's possible ?

["Tor Lillqvist" <tml iki fi>]

You need to add a call to g_thread_init(NULL) in main() before calling
gtk_init(). the libgconf library causes g_thread_init(NULL) to be
called inside the libORBit library.

The g_thread_init() documentation says: "You must call g_thread_init()
before executing any other GLib functions in a threaded GLib program."
This is quite vague. It means, in practice, "if you call any functions
from any GLib-based library, and you are not absolutely sure that the
library call will not cause g_thread_init() to be called, you should
call g_thread_init(NULL) yourself right at the start of main(). Better
safe than sorry."

Yeah, this is idiocy in my opinion... No idea how to fix it, though.
Probably every library that currently calls g_thread_init()
*somewhere* should instead call it in *every* function user code might
call first from it. Suitably protected to prevent double calls,
obviously, i.e.:

    if (!g_threads_got_initialized)
        g_thread_init (NULL);


What happens in your case is specifically that a
g_static_rec_mutex_lock() call hangs. If you check that function, and
the corresponding g_static_rec_mutex_unlock(), you see that they don't
do anything if g_thread_init() has not been called. What happens is
that for the class_init_rec_mutex in gtype.c, it is "locked" (but
remember that before g_thread_init() has been called, "locking" a
static recursive mutex is a no-op) while g_thread_init() gets called.
then it is unlocked. This screws up the mutex data structure, when the
underlying CRITICAL_SECTION gets initialised and then "leaved"
(unlocked) without having been first "entered" (locked). Or something
like that.

--tml