Re: closure threading issues

[Tim Janik <timj gtk org>]

On 1 Apr 2001, Owen Taylor wrote:

> Tim Janik <timj gtk org> writes:
> 
> > On 30 Mar 2001, Owen Taylor wrote:

> Well, if that's the case, then, well, we need to fix our current
> setup:
> 
>  - The point of the marshal guards is so that weak referenced data
>    that the closure holds a pointer to can be strongly referenced
>    during the invocation.
> 
>  - If you have weakly referenced data, then it the only reasonable
>    thing to do is that when that data is destroyed, to remove
>    the closure so that it doesn't get invoked in the future.
> 
>  - A class closure, by its very nature, must be set when the 
>    class is initialized and not removed until the class is
>    finalized.
> 
>  - Hence a class closure cannot have weakly referenced data.
>  
>  - Hence marshal guards are not useful for class closures
> 
> If you want to keep changes to the current code as small as
> possible, here's a suggestion:
> 
>  - Upon installation of a class closure, set the in_marshal
>    flag and pre-invoke

ok, with a bit of internal hackery, that'd be easy to add.

>  - Upon class finalization, unset the in_marshal flag and
>    post-invoke.
> 
> That deals with the in_marshal case. All that's left for mutation is
> the ref-counting.
> 
> One possibility would be to add atomic increment/decrement macros to
> GLib - not hard to find and useful for other things as well.  The
> other possibility is to add a flag to GClosure -
> refcount_upon_invocation.

i'd much prefer atomic increments/decrements.
sebastian, do you have time to give such an implementation a shot?

> 
> Regards,
>                                         Owen
> 

---
ciaoTJ