Re: closure threading issues
- From: Tim Janik <timj gtk org>
- To: Owen Taylor <otaylor redhat com>
- Cc: Havoc Pennington <hp redhat com>, Sebastian Wilhelmi <wilhelmi ira uka de>, Karl Nelson <kenelson ece ucdavis edu>, Gtk+ Developers <gtk-devel-list gnome org>
- Subject: Re: closure threading issues
- Date: Sun, 1 Apr 2001 23:23:31 +0200 (CEST)
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]