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.
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
