David Matthews wrote:
Robert Roessler wrote:
This could still potentially be handled by a C-style interface, if we could optionally associate a C "finalize" function with a volatile - this function could be called by the Poly memory reclamation when the volatile is truly unreachable; upon its return, Poly can go ahead and complete the free operation.
This issue comes up both in the general case of talking to extra-Poly code (where we may have some control of the interface presented), but also in the case of talking to an existing library that is C++ rather than C based... in this case, we really need to allow the foreign code base to perform its own lifetime-management related operations.
Like I said, this functionality may be available already... but if isn't, what are others' thoughts on the subject? Is this facility needed?
It seems like it could be useful. It isn't possible to run ML code while actually doing the garbage-collection so it would be necessary to record that a vol was due to be deleted and then call the finaliser at some point later on. That, of course, raises the question of which thread runs the finaliser. From a bit of searching it appears that in Java finalisers can be run on any thread which doesn't seem a good idea.
It may be possible to get the effect by using a weak reference (structure Weak). That requires a thread to monitor Weak.weakSignal and use that to then check which values have been deleted.
Probably because I already had a solution for this in my head (from what OCaml does), I wasn't clear...
The finalizer is intended to be *foreign* code, presumably C - and it is *never* able to do anying which affects the Poly heap(s). This is not as restrictive as it may sound, since the idea of the finalizer (as discussed here, anyway) is to manage the extra-Poly environment in any case.
I will look at this (in foreign.cpp?)... I will of course check the volatile implementation again, but aren't they handled specially WRT Poly saved state? As in, they do NOT persist?
That would be ideal, as the changes to support the foreign finalizer would be more contained... basically just an extra field per volatile value (or something like that), and API to set/get its value.
And the GC code to call the foreign function when the volatile is about to be reclaimed. ;)
A detail - finalizers are NOT allowed for Poly-owned volatiles.
Robert