[gambit-list] Wills from beyond.

Estevo 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).
> Marc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20131223/c6ddfe51/attachment.htm>

More information about the Gambit-list mailing list