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
_______________________________________________
polyml mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
