Just from the deleted wiki page on our google code project site: 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 On 2012-10-08, at 10:41, Fernando Olivero <fernando.olivero@usi.ch> wrote:
Yes, session management is cross-cutting concern, so it makes sense to have it in the system, and not just as a NB feature.
Object new, is a cool workaround for the unique ID!
Fernando
On Mon, Oct 8, 2012 at 8:33 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
Hello,
Yes, this sounds good.
Marcus
On Oct 8, 2012, at 5:11 AM, Igor Stasenko <siguctua@gmail.com> wrote:
I wanna have this:
SmalltalkImage>>snapshot: save andQuit: quit ... resuming ifTrue: [ session := self newSession ]. ...
(where session is additional instance variable of SmalltalkImage).
SmalltalkImage>>newSession "Just answer unique object, which never can be identical to any previous session object, this is all what we need for detecting session change. A session object don't needs to carry any state (we have plenty of other objects in image which can do this for us). it just needs to be unique"
^ Object new.
SmalltalkImage>>session ^ session
then, i can write in own code:
Smalltalk session == mySession ifFalse: [ self initForNewSession. mySession := Smalltalk session ]
So, basically, this little addition allows you to detect whether session changed or not between two different calls to your code (given that you remembered the previous session somewhere). Currently we don't have such feature, and looking how some existing code deals with session management, i see how it can be simplified. If you want to do something similar today, you will need to register in startup list.. which IMO stinks ;)
i don't like using startup lists, since you never know , what is the right order of resource initialization, and what inter-dependencies they may form, and changing dependencies over time will require changing startup order, again and again. Not fun. This technique allows you to lazily re-initialize any of your object(s) due to session change, once the control flow hits your code, but not before. (so you don't have to do all accounting at image startup time, you doing it only when it required/requested, which means shorter image startup time).
The notion of session is highly important for external resource management.
I using it in NativeBoost from very beginning, and wanna propose to use it globally.
-- Best regards, Igor Stasenko.
-- Marcus Denker -- http://marcusdenker.de