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.