Re: g_thread_init question



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...





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