[gst-devel] Possible race-condition when using g_enum_register_static
t.i.m at zen.co.uk
Thu Oct 18 12:15:05 CEST 2007
On Wed, 2007-10-17 at 20:32 +0200, Michal Benes wrote:
> gst_mad_emphasis_get_type (void)
> static GType mad_emphasis_type = 0;
> if (!mad_emphasis_type)
> mad_emphasis_type = g_enum_register_static ("GstFooBar", ...)
> return mad_emphasis_type;
> Isn't this racy when two mad plugins in two separate threads call this
> function for the first time? They clearly share the mad_emphasis_type
This is indeed racy.
> The problem is that the code like this is quite common in GStreamer.
> Am I wrong or is this a real problem?
I am not sure whether this really is a problem in practice, since these
_get_type() functions will first be called from within the plugin_init
function when the plugin is loaded and the element is registered [*],
and the plugin loading is serialised.
But then you've seen those warnings, so I must be missing something.
Patches to port these enum constructs to GOnce would be great in any
case, I think (see the glib-mkenums generated gstenumtypes.c).
What has been a problem in the past are things like custom GstBuffer
subclasses, which are usually only instantiated from streaming threads.
For those one has to do an explicit _class_ref() in the plugin_init
function to work around raciness in the type function and raciness in
GObject (when creating the class).
[*] gst_element_register() will do a g_type_class_ref() on the element's
GType, which will lead to the class_init function being called, which
will lead to the enum types being registered when the class_init
function registers the enum properties.
More information about the gstreamer-devel