Re: g_type_register_static and thread-safety

[Owen Taylor <otaylor redhat com>]

On Fri, 2003-07-04 at 04:08, Dave Benson wrote:
> Hello,
> 
> Almost all get_type() functions contain code
> like
> 
> GType
> whatever_get_type (void)
> {
>   static GType object_type = 0;
> 
>   if (!object_type)
>     {
>       static const GTypeInfo object_info =
>       { ...  };
> 
>       object_type = g_type_register_static (G_TYPE_OBJECT, "Whatever", &object_info, 0);
>     }
> 
>   return object_type;
> }
> 
> Is this thread-safe?  I cannot see any guards in
> g_type_register_static that prevent a second type-node from
> being allocated in the obvious race condition

No, it's not thread safe. You could have two type nodes allocated
or the second call to check_type_name_I() could fail.

The fact that whatever_get_type() isn't thread safe if "whatever"
is gtk_, but it is a problem for functions in libgobject, like 
g_closure_get_type().

A bug about this in bugzilla would be appreciated (I think we've
noted this before, but having it tracked officially would be
good). There are two relevant other bugs:

 - To fix the above without a fairly big speed penalty, you need GOnce:

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

   (The obvious fix, to make g_type_register_static() return the
    already registered type is the dubiously safe "double checked
    locking" idiom)

 - Fixing this for object types doesn't do you much good without
   also fixing:

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

What people do currently when using GObject in threaded applications
is to call g_type_class_ref (MY_TYPE_WHATEVER) for all their types
before creating the first thread. 

Regards,
						Owen