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 <[email protected]> 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 <[email protected]> wrote: >> Hello, >> >> Yes, this sounds good. >> >> Marcus >> >> On Oct 8, 2012, at 5:11 AM, Igor Stasenko <[email protected]> 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 >> >> >
