[gst-devel] Gtype registration error

[Tim Müller]

On Mon, 2008-04-28 at 12:50 +0200, Sebastian Dröge wrote:
 
> > Right, I think there are two types of issues, one in GLib with class
> > creation (which should be fixed in 2.16 AFAIK) and one with some of our
> > _get_type() functions. Since we have to work around the former anyway
> > for the time being there's little point in fixing up the latter quite
> > yet.
> 
> What is the issue with our get_type() functions? From what I
> understood the fix in GLib makes it unnecessary to wrap everything in
> g_once_init stuff.

If I remember correctly there are at least two issues:

(a) racy _get_type() functions:

GType
foo_bar_get_type()
{
 static GType mytype = 0;

 if (mytype == 0) {
   mytype = g_type_register (...);
 }
 return mytype;
}

This, when called from two threads at the same time, will lead to
'Cannot register existing type FooBar' warnings from GLib, which are
annoying, but -- at least as far as I know -- harmless, since the
underlying GLib code does do proper locking. The race condition here is
that 'mytype' is not being protected by a mutex, so there's nothing GLib
can do about this. The GOnce stuff in connection with the _get_type()
functions fixes this race condition and avoids the warnings.


(b) class creation isn't/wasn't thread-safe in GLib

This is the infamous

  http://bugzilla.gnome.org/show_bug.cgi?id=64764

(proxied in GStreamer as #349410 and #474823 and others).

This is what the g_class_ref() works around and what is fixed in
GLib-2.16.



> From what I understood the fix in GLib makes it unnecessary to wrap
> everything in g_once_init stuff.

I think the GOnce stuff for the _get_type() functions is still needed,
unless GLib dropped the 'existing type' warning and silently returns the
existing type now - doesn't look like it from the code in trunk though.

 Cheers
  -Tim