Notes on all the different ways that processes can be related to one another.

Parent/Child

When one process creates another using the fork(2) system call, the former is recorded as the parent of the latter, while the latter becomes a child of the former. Significance of parent/child relationship:

• The parent is allowed to change the process group ID of the child (as long as the child has not done an execve(2) call).
• When the child terminates, the parent can get a notification, either via the wait(2) or waitpid(2) calls, or by enabling receipt of the SIGCHLD signal.
• If the parent should terminate before the child, the child is given a new parent, the InitProcess?.

ProcessGroup

A process group is a set of processes all sharing the same process group ID. This is the ID of the process that created the group. Typically a shell will create a new process group for all processes that are part of a single shell pipeline.

Process groups are used to arbitrate access to the ControllingTerminal; to avoid user confusion processes currently in the foreground process group are the only ones allowed to read from this terminal (the assumption is they are all cooperating on the same task), while those in other process groups are blocked from doing so.

E.g. consider the following shell command:

    find bin -printf '%f\n' | xargs make

The shell spawns two initial processes in this process group: one running find, the second running xargs. The latter will in turn spawn another process, which goes by default into the same group, running make. And make, in turn, will likely spawn other processes to run compilers or whatever other else is necessary to rebuild the targets returned by the find command, depending on what's in the makefile.

Because the above command did not end with "&", the new process group is immediately put into the foreground, and the shell waits for the initial processes that it created to terminate before prompting the user for the next command.

Session?

A session is a set of processes all spawned (directly or indirectly) by the same session leader. A login shell is a session leader, and all processes it spawns in response to user commands are (at least initially) part of that same session. Any process can make itself into the leader of a new session by calling setsid(2), though it is probably a good idea to detach from its ControllingTerminal first.

See Also

Concepts of Job Control