<div dir="ltr"><div><div>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.<br>
<br></div>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.<br>
<br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Dec 23, 2013 at 3:14 PM, Marc Feeley <span dir="ltr"><<a href="mailto:feeley@iro.umontreal.ca" target="_blank">feeley@iro.umontreal.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
On Dec 22, 2013, at 9:35 PM, Estevo <<a href="mailto:euccastro@gmail.com">euccastro@gmail.com</a>> wrote:<br>
<br>
> Thanks for the detailed explanation.<br>
><br>
> > The GC only calls the finalizer (release function?) when it reclaims the space of the object.<br>
> > So as long as you can get your hands on o2 (when w1’s action procedure is executed), the<br>
> > finalizer will not have been called.<br>
><br>
> 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,<br>
>   - is the fact that o1 hasn't been reclaimed yet keeping w1 alive?<br>
>   - will the reference to o2 in w1's action closure prevent it from being reclaimed before that closure is reclaimed?<br>
><br>
> 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?<br>
<br>
</div></div>Lets define some concepts more formally:<br>
<br>
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)<br>
<br>
2) weak reachability of an object: all the reachability paths of the object contain at least one weak reference<br>
<br>
3) strong reachability of an object: at least one of the reachability paths of the object contain only strong references<br>
<br>
4) reachability of an object: an object that is either weakly reachable or strongly reachable<br>
<br>
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).<br>
<br>
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.<br>

<br>
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).<br>

<span class="HOEnZb"><font color="#888888"><br>
Marc<br>
<br>
</font></span></blockquote></div><br></div>