Re: g_thread_init question

["Alan M. Evans" <ame1 extratech com>]

On Wed, 2005-06-01 at 12:25, Tristan Van Berkom wrote:
> Alan M. Evans wrote:
> > If I make a class that internally uses threads and mutexes, how do I
> > protect myself against another class (not necessarily mine) created in
> > another thread (not necessarily under my control) also calling
> > g_thread_init() because it is also internally using gthread?
> 
>      That sounds conceptualy broken, if I instantiate a GObject that
> is a GtkWidget, the GtkWidgetClass initializer will not call gtk_init()
> for me, so why should an object using the thread system have to call
> g_thread_init () ?

The comparison lacks parity, in my opinion. It seems unlikely to me that
a class which uses GtkWidget would be used in a non-GTK+ program.
("Class" in the C++ sense, not the GObject sense.)

On the other hand, It seems completely feasable that a class that uses
GLib types and threads might be used in an application which has no
knowledge of GLib. In fact, that's exactly what I'm doing.

In other words, a shared object that uses GLib might not expose GLib,
but how would a shared object that uses GTK+ not expose that?

> Maybe it would be appropriate for the class initializer to do:
> 
>    if (!g_thread_supported ())
>         g_critical ("You must initialize the thread subsystem "
>                     "to use MyObjectClass");

Perfectly appropriate in an environment where GLib is assumed to be part
of the development chain. Not so when the application  developers (think
Win32) have never heard of GLib.