I was informed that save() restore() is not a common concept.... In running our simulations we need the ability to simulate to a point and save the state of the run.

Are you talking about:

• a continuation type of functionality, whereby you obtain a handle to the current state of execution at some point(s) within the execution of a given run, and can then return to that snapshoted state at some later point(s) within that same run.

Or

• A java-style hibernate facility whereby a snapshot of the thread is saved to disk and can be restored in a completely different run of the program at a later date?

To my knowledge, neither is currently available for ithreads, but (at least in an off-the-top-of-my-head, completely speculative theory), both might be possible. Either would be a considerable amount of work.

My basic idea is to use demerphq's Data::Dumper::Streamer module with it's ability to serialise datastructures (including (some?) coderefs), to disk and restore them; and apply it to the thread's defstash (You'll need to search for that term manually).

I've no idea if this is actually possible, or what the results would be if you attempted to restore the default stash without all of Perl's internal stacks etc., but it might be fun to explore the possibilities.

Update: On Win32, the fork emulation effectively clones a thread, state, run context et al. If this is your target platform, that might also form the basis of an attack. If you forked the thread and left the clone suspended--you could resume it at a later point.