> On 18-04-2016, at 8:59 AM, marcel.taeumel <Marcel.Taeumel at hpi.de> wrote:
> 
> I think the goal here is to allow applications to keep their resources open
> if snapshotting does not entail quitting. Whatever the reasons may be.

A generally laudable aim in my view. We should try to make it so that the minimum possible is done when saving a snapshot - I’d even stop hibernating bitmaps personally - but that does entail making the startup code able to do almost all the cleanup and restart. The problem with that is the amount of startup work is already ridiculous.

We could - as a gedankenexperiment - imagine doing nothing at all before the snapshot primitive. What would we need to do on a fresh startup to cope with whatever mess that left in the saved image? Is it noticeably different to what we already do? Can that be reduced?

I can see some things that would almost certainly want to be handled even on a save-and-continue; a database might very well want to do a synchronise, for example. But do sockets and file handles and stuff need to do anything?
I can see value in doing a gc before the save. I think. Maybe not? A gc and deal with dead weak pointers? That would potentially close down any dormant resources, which is something we’d be wanting sorted anyway.

If we’re quitting and saving then it makes sense to do all the important cleanups - close files, sockets, databases, shutdown connections to gpio deamons before the save, since that means the saved image will be cleaner and starting it up will go faster. If we’re quitting and not saving, maybe there are things that no longer need doing amongst the list.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Never do at  compile-time what you can put off till run-time