[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