[gambit-list] Wills from beyond.

Estevo euccastro at gmail.com
Mon Dec 23 13:55:40 EST 2013


>
>
> Will action procedures are “single shot”.  When the GC detects that an
> object has become weakly reachable, it schedules the will’s action
> procedure to be executed.  This happens only once.  If you want to detect
> subsequent transitions from strongly reachable to weakly reachable, just
> create a new will for this.
>
>
The problem I'm having is that I wanted to use wills to do something when I
knew for sure that an object was never going to be reachable from user code
again.

I wanted to fake references between foreign objects, so object A would not
be reclaimed as long as object B is reachable from user code.

My plan was/is to make a will with B as testator and a closure on A as
action.  The action would do nothing[1], but the closure reference would
keep A reachable and thus prevent it from being reclaimed.

This would feel safe enough for using in my own code, but I'd be more
remiss to offer this as a library for others to use.  The scheme is
defeated by the fact that as long as B is weakly reachable (e.g. by a will
or through a table with weak keys/values), it can be made strongly
reachable again by user code in a number of ways.  So the user could get in
a state where B is reachable but A has been freed.  This is a problem if A
is a C struct and B is a struct embedded in A.

I think I can solve the original problem in a less expensive way by giving
the user ___alloc_rc'ed foreign objects and using the data field in these
objects to create the reference to A from B.  I'll explore this further
now; I was just trying to exhaust what could be done with Scheme code (i.e.
with wills) first.

Thank you very much for your clarifications!

[1] Or it would do just enough to prevent the compiler from optimizing out
the reference to A; I haven't checked whether this could be a problem yet.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20131223/f0bbd542/attachment.htm>


More information about the Gambit-list mailing list