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