Squeak startup and shutdown lists are iterated too often, and startup is ignored by the network classes.

Introduction

Squeak/Pharo Problems

Squeak's startup and shutdown lists are not used as such. Each snapshot forces a shutdown and then a startup. This is not only inefficient, it is unfair to things like open sockets, database connections, etc. Platform windows will not be well served: imagine shutting down the entire IDE for a snapshot; something needs to be done.

Dolphin's Solution

Dolphin solves the problem through session managers that control the startup and shutdown sequences; they polymorphically adapt to manage deployed GUI applications, the IDE, console applications, etc. Events triggered off of a singleton session manager sub-instance assist in external resource management.

Dolphin does not free external resources on a snapshot. Resources are freed on shutdown (by registering for the shutdown events) and pointers/handles are cleared on startup. Having worked with it for years, I have gone from considering it strange to believing it is the correct design.

First Steps Toward a Fix

It became clear that my life would be easier given a singleton SessionManager that triggers #sessionStarted and #sessionStopped. The open question was whether Squeak's startup and shutdown lists with the quitting and resuming flags would be enough to reproduce Dolphin's behavior, which is to trigger #sessionStarted and #sessionStopped when and only when the image starts and stops, respectively. Somewhat surprisingly, it appears to be. I am left wondering why people have tolerated the need to litter images with #initializeNetwork sends; that should be done once every time the image starts.

Code

See

http://code.google.com/p/pharo/issues/detail?id=1200