Introduction

A restartable process can be reconstructed rapidly from a process image (text and data) without accessing stable storage. The management of restartable processes is handled by a ChorusOS supervisor process known as the Hot Restart Controller. The Hot Restart Controller is responsible for:

• Loading and running restartable processes, and controlling their storage in persistent memory.

• Monitoring restartable processes for abnormal termination, and restarting their restart group if an abnormal termination occurs.

• Triggering a site restart if a group is restarted too frequently (based on a system's restart policy, as described in "Getting Started with Hot Restart").

The following section looks at the API provided by the Hot Restart Controller and the corresponding restart-related commands provided by the C_INIT process. Before proceeding to a description of the API, however, it is important to understand how a restartable process is managed within the system.

Types of Restartable Processes

Processes do not explicitly declare themselves restartable, that is, there is no function call to declare a process restartable at the start of its main() program. Instead, a process can be run as a restartable process. Specifically, a process can be run as either a direct or indirect restartable process:

• Direct restartable processes are loaded and run using the C_INIT command arun with the -g option.

• Indirect restartable processes are spawned from restartable processes using the hrfexec(2RESTART) family of API calls. hrfexec() calls operate in a similar manner to afexec() calls, but provide an additional PmmName parameter. The PmmName parameter is used to identify the calls used for the purposes of process restart:

  #include <hr/hr.h> 
  int hrfexecve( PmmName *       baseName,
                 const char *    path,
                 KnCap *         cprocesscap,
                 const AcParam * param,
                 char const *    argv,
                 char const *    envp);
  (...)

The distinction between direct and indirect processes is important in understanding the automatic restart mechanism provided by the Hot Restart Controller. When an error occurs, the Hot Restart Controller first stops all processes in the group. After the processes are stopped, only the direct restartable processes will be restarted. These processes (re-executed from their initial entry point) are responsible for restarting any indirect processes they may have spawned.

Restartable Process Credentials

Restartable processes, just like traditional ChorusOS processes, are identified in the system by a unique capability and PID. Restartable processes also run in a user group (with a user ID) like traditional ChorusOS processes. The life of each of these credentials is the same as the life of a specific run-time instance of the process -- when a restartable process is restarted, it is given a new capability, PID and user ID.

Hot restartable processes also have two additional credentials which persist across a process restart, and characterize the processes in the Hot Restart Controller:

• Each restartable process has a unique name. The maximum number of restartable processes (unique names) that can be registered in the Hot Restart Controller is fixed by the hrCtrl.maxprocesses system parameter.

  ---

  Note -

  It is the programmer's responsibility to ensure that each process running in the system uses a unique name because this is not checked by the system. Attempting to run two processes that use the same name will cause unpredictable results.

  ---

• Each restartable process is a member of a restart group. A restart group is uniquely identified in the system by an integer (known as the group's ID). The maximum number of group IDs in a system is fixed by the hrCtrl.maxGroups parameter.

Restartable Processes and Persistent Memory

As previously discussed in "Memory Requirements and Design Constraints", the system uses persistent memory to store the following data for each executing restartable process:

• The process's process image: a copy of the text and initialized data segments from which the process will be loaded after a restart.

• The process's executing image: a copy of the text and data from which the process is executed.

This data is stored in three persistent memory blocks. One memory block is used for the process image, one is used for the executed text, and the last is used for the process data. These blocks are allocated and freed upon requests from the Hot Restart Controller to the Persistent Memory Manager. Other processes cannot access or free these persistent memory blocks. However, restartable processes can allocate additional blocks under the control of the Hot Restart Controller. This is described in "Freeing Persistent Memory".