Phil,
The idea of loadState is to be able to load information saved in a
previous session and it doesn't always work as expected when you reload
the state into the session that saved it. That isn't something I
imagined someone wanting to do.
loadState restores the values of references in the executable to the
values they had when the state was saved and this typically involves
loading additional mutable and immutable data. Any existing saved state
in the session is discarded but that raises the question of what happens
if a thread, in particular the one actually calling loadState, is using
some of the data in the old saved state. To allow this to work the
contents of the old saved state is moved into the local heap before the
new saved state is loaded. Most or all of it will then get garbage
collected away. The effect of this is that if you happen to load the
same state that has previously been loaded or saved then any objects
will be duplicated. There's no check that a state is actually the same
as one that was previously in the session, either loaded or saved, and
in any case I'm not sure there should be.
David
Philip Clayton wrote:
David,
Thanks. This makes sense and explains why we were seeing an inactive
thread. It's useful to know that values can be passed from one sessions
to the next via the stack - we hadn't fully appreciated that feature.
This behaviour with threads works well for what we are trying to do but
there is still something we can't explain or see how to work around:
after a loadState, when the running thread retrieves a referenced value,
it no longer appears to pick up the latest value. I've provided an
example that demonstrates this below. Is there a way for the thread to
pick up assignments to the ref variable 'c' after the loadState?
Thanks,
Phil
_______________________________________________
polyml mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
