On 18/09/2015 13:50, Phil Clayton wrote:
The only other changes I'm thinking about are:
1. Introducing a "touch" primitive for long-term security in case a
future update to the optimiser means that the current "touch" becomes a
no-op.
I think that would be a very good idea.
I've done that now. It's a new run-time system call which just returns
0. RTS calls are used for all built-in functions and it's possible for
the code-generator to process simple ones directly inline. I haven't
done that at the moment so it goes as far as a piece of assembly code.
2. Simplifying the Weak structure by removing everything except the
"weak" function. weakSignal and weakLock were really intended to allow
users to write their own finalisation code but if we have finalisers
provided they're probably unnecessary. There would obviously have to be
a way to wake up the finaliser thread. Currently it's integrated with
the signal handler thread in a non-obvious way.
I think I'll leave that for the moment.
Also, is there any point in Weak.weak taking an optional value? (Would
anyone ever call it with NONE?) Presumably weak could add the required
SOME to give
val weak : 'a ref -> 'a ref option ref
My thinking was that you might have a finite set of resources, such as
file descriptors, and a list of weak references or a weak array with an
entry for each resource. When a resource was allocated a SOME entry
would be made in the weak ref/array. If the resource was no longer
reachable the corresponding entry would be set to NONE and the resource
could be reclaimed and later reallocated.
David
_______________________________________________
polyml mailing list
polyml@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
