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
value while processes are referred to by
values. Contrarywise, Win32 uses a single
type to describe any object. Therefore, Boost.Process abstracts these handles
in each class where it makes sense using types named
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:
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.
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
Process groups are implemented by the
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.
represents a process' startup command line.
This concept is implemented by the
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.
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.
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
template and the
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
object that represented it.
Status concept is used
to represent a process' exit status.
This concept is implemented by the
|Copyright © 2006 Julio M. Merino Vidal|