Restore to previous state with copy-on-write

[zmbc]

Apologies if this isn't the right place for this kind of feature request.

As a Jupyter user, I would find it incredibly helpful if there was an "undo" for kernels. Frequently, I run something, only to realize it was the wrong thing and I want to go back one cell. If the bad cell had any destructive effect, this means I need to restart my kernel and run all the cells above again. If those cells took 3 hours to run, I need to wait 3 hours again. Even if I don't think the bad cell had any destructive effect, if I fix up the notebook mid-stream others (and myself) won't be 100% sure that the notebook would work with a simple "restart and run all."

I wish there were a command like "Kernel -> Save Checkpoint" and then the ability to restore back to checkpoints. In Jupyter, if this worked in tandem with the checkpointing of the notebook file itself, it could create a seamless experience: I create a checkpoint, make a mistake, restore both kernel and notebook to the checkpoint, fix the mistake and keep running, and I end up with exactly the notebook I would have had if I hadn't made the mistake in the first place. (On the Jupyter side I'd also like an option that automatically checkpointed after each cell, and one that forks off into a console instead of checkpointing the notebook file.)

Technically, it seems like this could be achieved through fork's copy-on-write mechanism. For many notebooks that don't have much volatile state that is rewritten multiple times, even checkpoints after every cell could have near-zero memory overhead -- they would just be forks of the kernel process at that point, using the same pages in memory as the active kernel process unless they are subsequently modified.

[davidbrochart]

Thanks @zmbc, that's an interesting idea.
Would you like to experiment with this idea through a PR?

[maartenbreddels]

Great idea, I worked a bit on this: #410 maybe it is helpful

[zmbc]

@davidbrochart would you be able to provide review/feedback on my PR #1261?

[zmbc]

@bluss commented on #1261 that forking doesn't work with threads, which is highly unfortunate and maybe sinks this idea.

I wonder if a less "fancy" but workable version of this feature would be a way for an ipykernel to persist its state to disk, and for a new kernel to be started from the file. It could use cloudpickle, and just fail when the user had variables that couldn't be pickled. Thoughts?