Session Manager in Pharo

As of this week, I am into 8th Week of my GSoC. And I am currently working on using the clap-st for Pharo as a command line handler. In this blog post, I would like to go through session manager working in Pharo and it`s relation with command line handlers.

Firstly, what is a session manager? Session managers are generally programs which can store (save) and restore the current state of the systems. In this context ‘session’ refers to the ‘state of the system’ at the current instant. The session manager in Pharo also does the same thing. It takes care of starting and ending the registered handlers in an order. When an image starts, a new session starts and similarly when the image is, quit the session stops. And the session manager follows a ‘singleton’ design pattern. i.e at any point there is only one active session. As mentioned in the class comment of ‘SessionManager’ the important responsibility of the session manager is to take care of how services and resources are started up and shut down in the image at the beginning and at the end of a session respectively. Few of these services are access to graphic drivers, the standard input/output, etc. To manage the services, the session manager maintains two lists namely startup list and shutdown list. These can be accessed as follows.

SessionManager default startupList. an Array(a ClassSessionHandler(GlobalIdentifier) a ClassSessionHandler(SmallInteger) a ClassSessionHandler(Delay)... ClassSessionHandler(OmDeferrer) a ClassSessionHandler(LGitLibrary))

SessionManager default shutdownList. an Array(a ClassSessionHandler(LGitLibrary)... a ClassSessionHandler(SmallInteger) a ClassSessionHandler(GlobalIdentifier))

The shutdown list is exactly in the opposite order to the startup list. Usually, when a session is started, all the elements listed in the startup list are started up. And when a session is ended, all the elements listed in the shutdown list are shutdown.

All the methods registered in the startup list have methods like  #startup: and #shutdown: .  Upon startup of the session, the session manager sends the message ‘#startup:’ to all the elements in the startup list. The argument sent with the message is of type boolean, which indicates whether the image is being closed or saved. Similarly, when a session is terminated, the session manager sends the message ‘#shutdown:’ to all the elements in the shutdown list.

Apart from the SessionManager class there is also SessionCategory class which allows creation and managing of many categories for a session. For example Network, UI, System. This SessionCategory allows registration of session handlers into a category.  The session handlers can be assigned a priority while registering else it will be assigned a default priority value. The above-mentioned startup and shutdown lists are prioritized and the priorities are managed by session categories. The methods #categoryNamed: and #createCategory: are helpful to access and create categories respectively. And, to subscribe a resource handler to the startup and shutdown list, a handler ( a subclass of the AbstractSessionHandler class ) should be subscribed. One of the subclass of the AbstractSessionHandler, ClassSessionHandler is used to subscribe a class for startup and shutdown.

A session handler can be registered as follows:

SessionManager default
register: (ClassSessionHandler forClassNamed: self name)
inCategory: SessionManager default systemCategory.

The SessionManager class also has a method systemCategory which allows to prioritize the elements of the startup and shutdown list internally.

The SessionManager uses the snapshotPrimitive to restart an image from the point it was saved before. When an image is saved, the entire image is frozen at the point of snapShot using snapshot Primitive and more specifically the process that invoked the snapshot Primitive is frozen. When the image is re-opened the running image will return from the snapShot primitive (similar to fork() process) and the saved file will also boot a new session from the same frozen point.

This can be illustrated as follow:

   s1 := SessionManager default currentSession.
   Smalltalk snapshot: true andQuit: false. “Save image without quitting”
    s2 := SessionManager default currentSession.
    Smalltalk snapshot: true andQuit:true. “Save and quit image, then after reloading…”
    s3 := SessionManager default currentSession.
    s1 == s2.  “==> true” “Because image is not a booted so not a new session”
    s2 == s3.  “==> false” “Because image is booted so a new session is created”


What is the relation between CommandLineHandler framework and  SessionManager?

The CommandLineHandlers are either registered into the startup and shutdown list of the SessionManager. For ex: in the class side #initialize method, the class is registered into the SessionManager and in #startUp: method of the BasicCommandLineHandler, the current session is first accessed and in its deferredStartUpActions, it ‘new activate’ method is called. Which means, during the startUp list the BasicCommandLineHandler is first started which in turn waits for all the startUp items to finish and then activates the handler. So, this is how a SessionManager manages the startup and shutdown and command line handler gets initialized in the startup of an image and shuts down during the shutdown of the image.

Do give your feedback or comments below.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s