On 17/09/2015 11:50, Phil Clayton wrote:
Thanks for the example - it was a useful to see how to use the Thread
structure. And to see how easy it was. That's a nice library.
Attached is a first stab at implementing the FINALIZABLE signature shown
below, which is identical to MLTON_FINALIZABLE. The code is based on
the MLton implementation but with a number of differences. As mentioned
in the other email, there seems to be an issue with finalizers not being
run when exiting via OS.Process.exit.
Phil,
I've begun by adding your code to a Finalizable branch in the github
repository. The Finalizable structure and signature are included in the
basis library when "poly" is built. It looks good and there's just a
few points.
Your definition of "touch" should be fine. I think I now understand
what's happening. At the moment at any rate the Poly/ML optimiser views
the "store" as a single entity so it won't try to reorder or remove
assignments just because they occur to locations that a more
sophisticated analysis might show to be independent. By the way, I
think perhaps the reason you had that rather bizarre behaviour with your
previous definition of "touch" was that the address of the token was
still in a register. Calling "print" before calling PolyML.fullGC will
have replaced the address with something else.
I was wondering how finalisation should this interact with saving state?
Should the state of the finalizers be restored when loadState is
called? That is what will happen with the code as it currently is but
it is possible to change that so that the state is not affected by
loadState by using "non-overwritable" references.
I've altered the initialisation code slightly. It now uses
PolyML.onEntry to start the thread and install the atExit handler. This
ensures that these are run on every run. Have a look at
basis/BasicStreamIO.sml which also contains a "non-overwritable"
reference for the list of streams that must be closed when Poly/ML exits.
I wonder if the finalizers should be called outside updatePendingList
i.e. after "mutex" has been released? The problem at the moment is that
if a finalizer calls "new" it will deadlock. A finalizer should
probably not be creating a new finalizer but equally we don't want deadlock.
David
_______________________________________________
polyml mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
