Re: g_thread_init question

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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]