If you are willing to save a snapshot in a state in which resources
were not cleaned up -- and you're okay with that -- then one of two
things must be true, either:

  - You never intend to actaully consume that snapshot or,
  - you have code which is unnecessarily cleaning up resources when it
doesn't need to, so just remove that code

Is your use-case that you want to do a "quick save" which doesn't
clean up, and then, eventually, a "save and quit" which does clean up?

This assumes the image will never crash?  It assumes you would never
need to re-load the quick-saved image?  If so, then you should either
not save at all, or remove the clean up code.

I think the reasons do matter.  If we can't articulate WHY what we're
doing is a laudable aim, then we're just adding more and more API for
obscure things which no one will ever use.  This does not move us
toward a simpler system that anyone could fully understand.


On Mon, Apr 18, 2016 at 10: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.
>
> At the moment, we collected several opinions and use cases here, which
> suggest to provide two boolean variables, maybe "snapshotting" and
> "quitting", in the shutdown-interface. Then we would have three different
> flavors:
>
> #shutDown
> #shutDown:
> #shutDown:and:
>
> Or something like that. Classes can start using the new one if they want to.
>
> Best,
> Marcel
>
>
>
> --
> View this message in context: http://forum.world.st/Why-do-we-process-the-shutdown-list-if-not-snapshotting-tp4890384p4890685.html
> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>