Annotated edit history of
ProcessRelationships version 4, including all changes.
View license author blame.
| Rev |
Author |
# |
Line |
| 1 |
LawrenceDoliveiro |
1 |
Notes on all the different ways that processes can be related to one another. |
| |
|
2 |
|
| |
|
3 |
!! Parent/Child |
| |
|
4 |
|
| |
|
5 |
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: |
| |
|
6 |
|
| |
|
7 |
* 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). |
| |
|
8 |
* 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. |
| |
|
9 |
* If the parent should terminate before the child, the child is given a new parent, the InitProcess. |
| |
|
10 |
|
| |
|
11 |
!! ProcessGroup |
| |
|
12 |
|
| 4 |
MartinJerabek |
13 |
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''. |
| 3 |
LawrenceDoliveiro |
14 |
|
| |
|
15 |
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. |
| |
|
16 |
|
| |
|
17 |
E.g. consider the following shell command: |
| |
|
18 |
|
| |
|
19 |
<pre> |
| |
|
20 |
find bin -printf '%f\n' | xargs make |
| |
|
21 |
</pre> |
| |
|
22 |
The shell spawns two initial processes in this process group: one running <tt>find</tt>, the second running <tt>xargs</tt>. The latter will in turn spawn another process, which goes by default into the same group, running <tt>make</tt>. And <tt>make</tt>, in turn, will likely spawn other processes to run compilers or whatever other else is necessary to rebuild the targets returned by the <tt>find</tt> command, depending on what's in the makefile. |
| |
|
23 |
|
| |
|
24 |
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. |
| 1 |
LawrenceDoliveiro |
25 |
|
| |
|
26 |
!! [Session] |
| |
|
27 |
|
| |
|
28 |
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. |
| 2 |
LawrenceDoliveiro |
29 |
|
| |
|
30 |
!! See Also |
| |
|
31 |
[Concepts of Job Control|http://www.gnu.org/software/libc/manual/html_node/Concepts-of-Job-Control.html] |
