Boost C++ Libraries



2.1. Handle
2.2. Child process
2.3. Command line
2.4. Launcher
2.5. Exit status

The following subsections describe the basic concepts behind Boost.Process. They are first slightly introduced based on the operating system concepts behind them and are later specified as concepts to be used in templates.


A handle is an operating system entity that identifies one of its objects, such as a file or a process. Handles are used by user space programs to tell the operating system the object they are referring to.

Given the low-level interactions of Boost.Process with the operating system, the library lets the user access these handles, should he need them to call operating system services directly.

It is important to note that handles are object-specific. An operating system may use different data types to identify each of its objects. For example, POSIX systems refer to files through an int value while processes are referred to by pid_t values. Contrarywise, Win32 uses a single HANDLE type to describe any object. Therefore, Boost.Process abstracts these handles in each class where it makes sense using types named handle_type.

A process is the execution context of a program, represented internally by the operating system through multiple objects in its internal tables. Any reference to a process always mentions a running application in the system; it has to be clear that it cannot refer to an on-disk program that has not yet started execution.

Processes are internally organized by the operating system as a tree. Each process (except for the one at the tree's root) has a parent and can have multiple children. A parent process owns its children and therefore has full control over their execution.

There are two possible statuses for a child process:

  • Active: the process is alive. It may either be running or sleeping, but it has not finalized execution.
  • Zombie: the process finished execution and is waiting for its parent to collect its status. This may happen due to unexpected and expected termination conditions.

The Child concept represents a child process of the currently running application (that is, the program using Boost.Process services). The program can directly control the child process, send and retrieve data from it and collect its finalization status.

This concept is implemented by the child and posix_child classes.

The library also provides specialized process groups to maintain the status of complex operations such as the spawning of a process pipeline. These groups are aggregations of the previous Child implementations.

Process groups are implemented by the children class.

As already described, a process is the execution context of a program. This program is launched using a command line: a tuple that includes the binary to execute and the set of arguments passed to it.

The command line is thought as a standalone concept because it is important enough on its own. A command line can be constructed in multiple different ways so there might be multiple implementations to create one.

The Command_Line concept represents a process' startup command line.

This concept is implemented by the command_line class.

In order to spawn a child process, the parent needs to provide multiple data to the operating system. First, the new process needs a command line that tells the system what to execute. Second, it requires the attributes that specify internal process details. And third, it needs information that describes how the new process relates to its parent; this includes streams for communication among other details.

The attributes mentioned in the previous paragraph refer to all those properties that a process carries: its working directory, its security credentials, etc. The launcher may provide means to configure these for a new process.

The Launcher concept is an abstract representation used to model a process' startup procedure. As said above, a process is something that is already in the operating system tables: it cannot exist before the system has explicitly started it. Furthermore, by keeping the launcher separate from processes, the same execution context can be shared across multiple command lines painlessly.

This concept is implemented by the launcher and posix_launcher classes.

The library also provides specialized launcher to spawn process pipelines. A pipeline is a unidimensional chain of interconnected processes in which the output of one of them is connected to the input of the following.

Pipeline launchers are implemented by the basic_pipeline template and the pipeline class.

Upon termination, a process reports information to its parent describing why it finalized. This information is known as the exit status and includes the reason behind termination (regular exit, crash, external signal, etc.) together with details describing it.

Exit status can only be gathered from zombie processes; that is, child processes that stopped execution and are waiting for its parent to collect it. When the information is collected, the zombie process ceases to exist from the system tables, invalidating the Child object that represented it.

The Status concept is used to represent a process' exit status.

This concept is implemented by the status class.

Copyright 2006 Julio M. Merino Vidal