Compare text

Find the difference between two text files

Real-time diff

Unified diff

Collapse lines

Highlight change

Syntax highlighting

Tools

Untitled diff

Created 7 years agoDiff never expires

36 removals

93 lines

37 additions

95 lines

I am the object responsible of managing how sessions work in Pharo.

I am responsible for managing how sessions operate in Pharo.

A session defines the boundaries of work in the image.

A session is the period that an image is "live".

A new session starts when the image starts or when the image is saved.

A new session begins when the VM loads and boots an image,

A session ends when the image quits or it is saved.

A session ends when the image quits.

There is only one active session at a single point of time.

There is only one active session at a time.

Saving the image causes the active to stop, and starts a new session.

Saving the image causes the active session to

temporarily shutdown, so the image can be frozen to disk.

After saving, the active session resumes.

A new session is installed when the frozen disk image is next booted.

The current active session is hold by myself, the singleton session manager. It can be accessed by doing:

The current active session is held by myself, the singleton session manager. I 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.

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 appropriate times (boot, save, quit). 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:

Such initialization is invoked by the #snapshot:andQuit: method. This will...

- stop current session

- shutdown current session

- save current image if requested

- quit if requested

- quit, if requested

- start a new session

- install a new current session, if image is booting

- start-up the current 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:

When a session is started or shutdown, the elements registered in the following lists are processed...

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].

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 booted [quit].

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.

Finally, to subscribe some resource handler to the startup/shutdown lists, we need to subscribe a handler subclassed from 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.

The most common handler implementation so far is the ClassSessionHandler, that allows a class to register 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

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

inCategory: SessionManager default systemCategory

atPriority: 100.

SessionManager default systemCategory

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.

When the image is saved, using the snapshot primitive, the entire image is frozen at the point of the snapshot.

More particularly, the process that invoked the snapshot primitive is freezed at the point of the primitive call.

More particularly, the process that invoked the snapshot primitive is frozen 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.

This works similar to a native process fork(). The continuing session returns from the snapshot primitive and the saved file will also boot a new session from the same frozen 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.

The return value from the snapshot primitive differentiates whether we in the continuing session or are booting a new session.

Read the comment of #snapshotPrimitive for more details.

Saved diffs

Original text

Open file


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.

Changed text

Open file


I am responsible for managing how sessions operate in Pharo.
A session is the period that an image is "live".

A new session begins when the VM loads and boots an image,
A session ends when the image quits. 
There is only one active session at a time. 
Saving the image causes the active session to 
temporarily shutdown, so the image can be frozen to disk.  
After saving, the active session resumes.
A new session is installed when the frozen disk image is next booted.

The current active session is held by myself, the singleton session manager. I 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 appropriate times (boot, save, quit). 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 is invoked by the #snapshot:andQuit: method. This will...
 - shutdown current session
 - save current image if requested
 - quit, if requested
 - install a new current session, if image is booting
 - start-up the current session  
 

# Managing Startup and Shutdown lists

When a session is started or shutdown, the elements registered in the following lists are processed...

	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 booted [quit].

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 subclassed from AbstractSessionHandler.
The most common handler implementation so far is the ClassSessionHandler, that allows a class to register 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 frozen at the point of the snapshot.
More particularly, the process that invoked the snapshot primitive is frozen at the point of the primitive call.
This works similar to a native process fork(). The continuing session returns from the snapshot primitive and the saved file will also boot a new session from the same frozen point.
The return value from the snapshot primitive differentiates whether we in the continuing session or are booting a new session.

Read the comment of #snapshotPrimitive for more details.