Re: closure threading issues

[Owen Taylor <otaylor redhat com>]

I think the conceptual answer to this is really simple:

 - Class closures, and their associated data are associated with the 
   signal, which is associated with the class.
 - The class won't be unloaded until the object is finalized
 - The object won't be finalized until the call is finished.

So class closures don't need refcounting during invocation, and
since I don't think class closures should be mutating themselves
during invocation, they don't need locking either.

Regards,
                                        Owen

Tim Janik <timj gtk org> writes:

> hey owen, havoc, sebastian, kenelson,
> 
> with the recent addition of g_signal_newc() that internally creates
> a closure, we can theoretically have objects that don't live under
> a common global lock (like for instance Gtk ones) sharing a closure.
> closures themselves provide no extra guarding code wrg thread safety,
> and i'd rather leave it at that, since in general clashes here
> shouldn't occour and locks would prolly just slow down things
> (and the closure code is sufficiently complex already).
> 
> however, as mentioned above, that requires users to access objects
> of the same class only from within a single common lock, and as
> we move away from gtk/gdk objects, i'm not sure that requirement
> holds true anymore.
> 
> we'll have to choose either of:
> 1) the user has to provide threading guards at least per-class
>    that he uses objects off (i think that will break at pure
>    G_TYPE_OBJECT level already)
> 2) users will definitely use objects of the same class from
>    different threads (that's what applies to G_TYPE_OBJECT already
>    though we could make that an ugly exception with some closure
>    hacks)
> 
> i guess the outcome of this is (2) and that in turns requires proper
> gclosure.c locking that i don't feel overly comfortable with.
> usign one global closure lock is prone to cause a lot of runtime
> collisions, hurting performance, while using per-closure locks
> will considerably bloat memory.