eh! sorry, thats way too confusing to leave alone. I meant... I'm not sure I properly understand.
On Thu, Apr 27, 2017 at 12:17 AM, Ben Coman <b...@openinworld.com> wrote: > I'm sure I properly understand, you mean to change the behaviour rather > than the comment? > My naive understanding and intuition is the current behaviour is fine. > What do you see wrong with it? > > cheers -ben > > On Wed, Apr 26, 2017 at 11:46 PM, Guillermo Polito < > guillermopol...@gmail.com> wrote: > >> Hi Ben, true. >> >> This happens because of this line: >> >> "create a new session object if we're booting" >> isImageStarting ifTrue: [ self installNewSession ]. >> >> in SessionManager>>snapshot:andQuit: >> >> I'd say we should not change this now, but we should fix it for pharo 7. >> >> On Tue, Apr 18, 2017 at 6:15 PM, Ben Coman <b...@openinworld.com> wrote: >> >>> hi Guille, >>> >>> Thanks very much for that detailed write up. I have one concern about >>> the [bracketed] text... >>> A new session starts when the image starts [or when the image is >>> saved]. >>> A session ends when the image quits [or it is saved]. >>> >>> Doing the following in a playground... >>> s1 := SessionManager default currentSession. >>> "Save image without quitting" >>> s2 := SessionManager default currentSession. >>> "Save and quit image, then after reloading..." >>> s3 := SessionManager default currentSession. >>> s1 == s2. "==> true" >>> s2 == s3. "==> false" >>> >>> So it seems a new session does not start when the image is saved. >>> With that in minds, can you review my proposed modifications... >>> https://www.diffchecker.com/FUWg5J8t >>> >>> cheers -ben >>> >>> On Thu, Apr 13, 2017 at 5:41 PM, Guillermo Polito < >>> guillermopol...@gmail.com> wrote: >>> >>>> Hi all, >>>> >>>> I took some minutes to write down a class comment for the >>>> SessionManager class. There was an issue asking for it: >>>> >>>> https://pharo.fogbugz.com/f/cases/19463/Improve-SessionManag >>>> er-class-comment >>>> >>>> Since it is an important topic, and sometimes too low level for some >>>> people, I'd like to have some feedback. Is it well explained? Is there >>>> something that is key for you and is missing? >>>> >>>> I know that the comment is not exhaustive, it can be iterated and >>>> enhanced, but we can have a nice first version of it for the release. >>>> >>>> Thanks, >>>> Guille >>>> >>>> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>>> >>>> >>>> I am the object responsible of managing how sessions work in Pharo. >>>> A session defines the boundaries of work in the image. >>>> >>>> A new session starts when the image starts or when the image is saved. >>>> A session ends when the image quits or it is saved. >>>> There is only one active session at a single point of time. >>>> Saving the image causes the active to stop, and starts a new session. >>>> >>> >>> >>> >>> >>> >>>> >>>> The current active session is hold by myself, the singleton session >>>> manager. It can be accessed by doing: >>>> >>>> SessionManager default currentSession. >>>> >>>> The most important responsibility of the session manager is to manage >>>> how resources and services in the image are started up and shut down at the >>>> beginning and end of a session respectively. For example, when the image >>>> starts, several initialization routines should be executed to make sure >>>> that the image has access to the graphic drivers, the standard input/output >>>> file descriptors and so on. >>>> >>>> Such initialization happens in the #snapshot:andQuit: method. >>>> #snapshot:andQuit: will: >>>> - stop current session >>>> - save current image if requested >>>> - quit if requested >>>> - start a new session >>>> >>>> When a session is started, all elements registered in the startup list >>>> are started up. >>>> When a session is stopped, all elements registered in the shutdown list >>>> are shut down. >>>> >>>> # Managing Startup and Shutdown lists >>>> >>>> The startup and shutdown lists can be accessed through the messages: >>>> >>>> SessionManager default startupList. >>>> SessionManager default shutdownList. >>>> >>>> In general terms, the shutdown list is the startup list reversed. >>>> >>>> Upon a startup [shutdown], all elements in the startup list are sent >>>> the message #startup: [#shutdown:] with a boolean as argument that >>>> indicates wether the image is being saved [closed]. >>>> >>>> Internally, startup and shutdown lists are prioritised. Priorities are >>>> managed by startup categories. By default the session manager includes the >>>> following categories in decreasing priority order: >>>> >>>> - System >>>> - Network >>>> - Graphical User Interface >>>> - Tools >>>> - User >>>> >>>> Categories can be accessed as follows: >>>> >>>> SessionManager default categoryNamed: aName. >>>> >>>> New categories can be registered in the system using the messages: >>>> >>>> SessionManager default createCategory: aCategoryName. >>>> SessionManager default createCategory: aCategoryName after: >>>> anotherCategoryName. >>>> >>>> Finally, to subscribe some resource handler to the startup shutdown >>>> lists, we need to subscribe a handler, subclass of AbstractSessionHandler. >>>> The most common handler implementation so far is the >>>> ClassSessionHandler, that allows to subscribe a class for startup and >>>> shutdown, keeping backwards compatibility to the old startup mechanism. >>>> >>>> ClassSessionHandler forClassNamed: aClassName >>>> >>>> We can register a session handler as follows >>>> >>>> SessionManager default >>>> register: (ClassSessionHandler forClassNamed: self name) >>>> inCategory: SessionManager default systemCategory. >>>> Or alternatively, by talking to the corresponding category: >>>> >>>> SessionManager default systemCategory register: (ClassSessionHandler >>>> forClassNamed: self name) >>>> >>>> # System Category Priorities >>>> >>>> A system category internally prioritizes its elements to provide a fine >>>> grained control on the startup and shutdown order. >>>> All methods above have variants that allow developers to specify the >>>> priority inside the category: >>>> >>>> SessionManager default >>>> register: (ClassSessionHandler forClassNamed: self name) >>>> inCategory: SessionManager default systemCategory >>>> atPriority: 100. >>>> >>>> SessionManager default systemCategory >>>> register: (ClassSessionHandler forClassNamed: self name) >>>> atPriority: 100 >>>> By default, if no priority is specified, a default priority is used. >>>> Every category answers to the message #defaultPriority. >>>> >>>> # How does an image restart from the point it was before >>>> >>>> An important point in the image startup is how does it manage to >>>> restart from the point where it was executing when it was saved. >>>> >>>> When the image is saved, using the snapshot primitive, the entire image >>>> is freezed at the point of the snapshot. >>>> More particularly, the process that invoked the snapshot primitive is >>>> freezed at the point of the primitive call. >>>> This works as a process fork: the running image will return from the >>>> snapshot primitive and the saved file will also start from the freezed >>>> point. >>>> To differentiate whether we are executing in the running image or in >>>> the freshly-saved image, the snapshot primitive returns a boolean >>>> indicating it. >>>> >>>> Read the comment of #snapshotPrimitive for more details. >>>> >>> >>> >> >
