[gambit-list] Wills from beyond.
euccastro at gmail.com
Mon Dec 23 11:10:11 EST 2013
Thanks again Marc, this is great! My misunderstanding was that I thought
objects could be reclaimed anytime they are not _strongly_ reachable
anymore. I think this is how it works in Python (any use of weak
references to reclaimed objects raises a ReferenceError). Gambit's
approach is indeed more powerful, and I can now see how it will simplify a
problem I have.
So just to confirm: inclusion of a will in the executable or nonexecutable
will lists is/works like a weak reference, right? In the example I gave
before, w1 couldn't be reached weakly or strongly from the toplevel at the
point its action procedure got executed.
On Mon, Dec 23, 2013 at 3:14 PM, Marc Feeley <feeley at iro.umontreal.ca>wrote:
> On Dec 22, 2013, at 9:35 PM, Estevo <euccastro at gmail.com> wrote:
> > Thanks for the detailed explanation.
> > > The GC only calls the finalizer (release function?) when it reclaims
> the space of the object.
> > > So as long as you can get your hands on o2 (when w1’s action procedure
> is executed), the
> > > finalizer will not have been called.
> > After w1 and o2 have been set to #f, is there anything preventing the
> space for either of them to be reclaimed anytime? In particular,
> > - is the fact that o1 hasn't been reclaimed yet keeping w1 alive?
> > - will the reference to o2 in w1's action closure prevent it from
> being reclaimed before that closure is reclaimed?
> > A corollary to the latter: if I delay the execution of w1's action
> closure for long enough (e.g. by holding onto o1) could I ever get it to
> execute with o2_ pointing to freed/invalid memory?
> Lets define some concepts more formally:
> 1) reachability path of an object: a chain of references from the roots
> that reaches the object (these references can be a mixture of weak and
> strong references)
> 2) weak reachability of an object: all the reachability paths of the
> object contain at least one weak reference
> 3) strong reachability of an object: at least one of the reachability
> paths of the object contain only strong references
> 4) reachability of an object: an object that is either weakly reachable or
> strongly reachable
> Note that during execution, an object’s reachability may alternate between
> weakly reachable and strongly reachable (any number of times, as required
> by the program).
> The action procedure of a will is executed when the GC detects that the
> will’s testator object is weakly reachable. The GC is *not* taking the
> decision to reclaim the testator object, in fact it can’t reclaim the
> object since it is (at least) required to be passed as a parameter to the
> action procedure.
> The GC reclaims objects that are not reachable. When a foreign object is
> reclaimed by the GC, its release function is called (which may cause other
> “finalization” actions, such as reclaiming space on the C heap). Note that
> it is possible to force the execution of the release function by explicitly
> calling (foreign-release! obj). Those are the only situations when the
> release function is called. So if you don’t use foreign-release!, the
> Scheme code manipulating a foreign object has the guarantee that the
> release function hasn’t been called (regardless of whether the object is
> the testator of a will or not).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gambit-list