On Wed, 2005-06-01 at 14:28, Tristan Van Berkom wrote: > Alan M. Evans wrote: > > ("Class" in the C++ sense, not the GObject sense.) > > I am tempted to argue that "class" in the c++ sence *is* the same > as a "class" in the GObject sence; but that is a little off-topic :)
I knew you would be, and so would I. What I meant by that is, that a C++ API exporting a simple class makes no demands about the application knowing GLib. One which exports a GObject or descendant implies that the application know GLib. > The race condition is present only if you make it possible that > you call g_thread_init () from two seperate threads, to be blunt; > its your responsability to make sure that doesn't happen. I know that it's my responsibility. That is why I asked the question in the first place. > So lets say that you are writing an application that uses > GStreamer, GTK+ & your shared object, in your main () you > will call each of the following: > > void main () { > gtk_init (); // <-- calls g_threads_init () > gst_init (); // <-- calls g_threads_init () > my_customlib_init (); // your shared object library init point > // that will also call g_threads_init () > } I thought of this, but it seemed ... inelegant. Suppose I create a drop-in replacement for the Win32 CAsyncSocket class. (Not what I'm doing, by the way.) Now CAsyncSocket does not require calling some init procedure, but MyClass does. Not really a drop-in replacement, is it? I didn't come here to pick a fight. Honest. But it seems to me that this whole thing would be a non-issue if g_threads_init() would respond to a second call by returning instead of aborting. Imagine: void g_threads_init(GThreadFunctions *vtable) { static GStaticMutex only_once = G_STATIC_MUTEX_INIT; if (g_static_mutex_trylock(&only_once)) { g_threads_real_init(vtable); } } and no more aborting! I'm probably oversimplifying something there, but it seems to me that the proper place to assure something is exclusive is at the point of exclusivity (inside GLib) not independently by every user of the exclusive procedure. Sorry, now I'm ranting. I'll go away; just came here hoping there was another choice... _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list