In principle CPU registers aren't the biggest problem if the VM supports it somehow (I don't know if perl 5 does continuations internally; if yes, they could be serialized. But somehow I doubt it). Kernel drivers that do suspend-to-disk get around this problem somehow.
But there are other problems like pipes, sockets, open file handles (for example under Linux you can have an open file handle to an unlinked file - you can't really restore that) and network connections, and you have to think about what you do with $^T, for example.
All in all I think it's easier to make that particular application serialize its data and dump it to disk, and then resume later on. | [reply] |
But there are other problems like pipes, sockets, open file handles...
As they are all process global entities, so long as the process continued running, they would persist, and once the thread was restored, it could continue to use them. All the caveats about changes to them and other process global state like $^T are essentially the same as if the thread had slept, or been suspended.
Equally, these problems exist with existing mechanisms for suspending (hibernating) processes to disk (think laptops). If anything modifies the state of the filesystem between suspend and resume, things get screwy. If you close you laptop while programs are connected to the net, they probably won't like it much when you try to restore them. Some protocols like http being connectionless, mean that browser can redisplay the cached state of pages and interaction can continue, assuming a new connection has been established. But you'll have less luck with most other protocols.
Perl 5 doesn't do continuations, or anything close to them. Hence the reason I say the register state is the biggest insurmountable problem.
In theory, as iThreads are always clones of their 'parent' (notional only), then if you could 'capture' the state of a thread immediately after it is created, but before tranfering control to it, you would have a restorable, known state.
So, to save the state of a thread, you would have it spawn a new thread--which would be a clone of itself--and then immediately die. The thread procedure for that new thread could then serialise itself to disk and die also.
The problem then comes at restoration. You spawn a new thread to restore the serialised one from disk, but it will be a clone of it's parent--there's currently no way to avoid that (more's the pity)--so the deserialise thread proc would have to clean itself of inherited state, prior to reconstructing the saved state.
And that's currently not doable by any stretch of my imagination.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l] |
