Process group: Difference between revisions
Sharpen category. |
"where where " -> "where" |
||
Line 9: | Line 9: | ||
The <code>setpgid()</code> system call is a general-purpose call for creating new or joining existing process groups; to become a process group leader using it, a process has to set its own process group to the same value as its own process ID, usually with the call <code>setpgid(0,0)</code>. When the shell <code>[[fork (operating system)|fork]]</code>s a new child process for a command pipeline, both the parent shell process and the [[child process]] immediately attempt to make the process into the leader of the process group for the command pipeline. (They both attempt to do the same thing in order to avoid a [[race condition]] between the child becoming the process group leader, the child executing the program image of the command being executed, and the parent, or the tty device driver, attempting to send signals to the process group for job control.) |
The <code>setpgid()</code> system call is a general-purpose call for creating new or joining existing process groups; to become a process group leader using it, a process has to set its own process group to the same value as its own process ID, usually with the call <code>setpgid(0,0)</code>. When the shell <code>[[fork (operating system)|fork]]</code>s a new child process for a command pipeline, both the parent shell process and the [[child process]] immediately attempt to make the process into the leader of the process group for the command pipeline. (They both attempt to do the same thing in order to avoid a [[race condition]] between the child becoming the process group leader, the child executing the program image of the command being executed, and the parent, or the tty device driver, attempting to send signals to the process group for job control.) |
||
Process groups are themselves grouped into '''sessions'''. Where a [[text terminal|textual user interface]] is being used on a Unix-like system, sessions are used to implement '''[[login session]]s'''. (This concept is largely lost, and the [[kernel (computer science)|kernel]]'s notion of sessions largely ignored, |
Process groups are themselves grouped into '''sessions'''. Where a [[text terminal|textual user interface]] is being used on a Unix-like system, sessions are used to implement '''[[login session]]s'''. (This concept is largely lost, and the [[kernel (computer science)|kernel]]'s notion of sessions largely ignored, where a [[graphical user interface]] is being used. Graphical user interfaces, such as where the [[X display manager]] is employed, use a different mechanism for implementing login sessions.) A single process, the '''session leader''', interacts with the controlling terminal in order to ensure that all programs are terminated when a user "hangs up" the terminal connection. (Where a session leader is absent, the processes in the terminal's foreground process group are expected to handle hangups.) Processes are not permitted to join process groups that are not in the same session as they themselves are, process groups are not permitted to migrate from one session to another, and a process may only create new process groups belonging to the same session as it itself belongs to. |
||
The <code>setsid()</code> system call is used to create a new session. If it succeeds, it always makes a process into a process group leader, because its purpose is to create a new session containing a single (new) process group, with the current process as both the leader of the session and of that single process group. |
The <code>setsid()</code> system call is used to create a new session. If it succeeds, it always makes a process into a process group leader, because its purpose is to create a new session containing a single (new) process group, with the current process as both the leader of the session and of that single process group. |
Revision as of 22:29, 5 July 2006
In POSIX-conformant operating systems, a process group denotes a collection of one or more processes. The collection is identified by a positive integer, the process group ID, which is the process identifier of the process that is (or was) the process group leader.
Process groups are used to control the distribution of signals. The kill system call is capable of directing signals either to individual processes or to process groups. A signal directed to a process group is delivered individually to all of the processes that are members of the group.
The distribution of signals to process groups in turn forms the basis of job control employed by shell programs. The tty device driver incorporates a notion of a foreground process group, to which it sends the SIGTSTP, SIGQUIT, and SIGINT signals generated by keyboard interrupts. It also sends the SIGTTIN and SIGTTOU signals to any processes that attempt to read from (and, if appropriate flags are set for the terminal device, write to) the terminal that are not in the foreground process group. The shell, in turn, partitions the command pipelines that it creates into process groups, and controls what process group is the foreground process group of its controlling terminal, thus determining what processes (and thus what command pipelines) may perform I/O to and from the terminal at any given time.
Process groups need not necessarily have leaders, although they always begin with one. POSIX mandates that processes may not accidentally become process group leaders. To this end, it prohibits the re-use of a process ID where a process group with that identifier still exists (i.e. where the leader of a process group has exited, but other processes in the group still exist). To become a process group leader, a process explicitly invokes the setpgid()
or the setsid()
system call.
The setpgid()
system call is a general-purpose call for creating new or joining existing process groups; to become a process group leader using it, a process has to set its own process group to the same value as its own process ID, usually with the call setpgid(0,0)
. When the shell fork
s a new child process for a command pipeline, both the parent shell process and the child process immediately attempt to make the process into the leader of the process group for the command pipeline. (They both attempt to do the same thing in order to avoid a race condition between the child becoming the process group leader, the child executing the program image of the command being executed, and the parent, or the tty device driver, attempting to send signals to the process group for job control.)
Process groups are themselves grouped into sessions. Where a textual user interface is being used on a Unix-like system, sessions are used to implement login sessions. (This concept is largely lost, and the kernel's notion of sessions largely ignored, where a graphical user interface is being used. Graphical user interfaces, such as where the X display manager is employed, use a different mechanism for implementing login sessions.) A single process, the session leader, interacts with the controlling terminal in order to ensure that all programs are terminated when a user "hangs up" the terminal connection. (Where a session leader is absent, the processes in the terminal's foreground process group are expected to handle hangups.) Processes are not permitted to join process groups that are not in the same session as they themselves are, process groups are not permitted to migrate from one session to another, and a process may only create new process groups belonging to the same session as it itself belongs to.
The setsid()
system call is used to create a new session. If it succeeds, it always makes a process into a process group leader, because its purpose is to create a new session containing a single (new) process group, with the current process as both the leader of the session and of that single process group.
References
- Single UNIX Specification, Issue 6
Further reading
- Marshall Kirk McKusick and George V. Neville-Neil (2004-08-02). "FreeBSD Process Management: Process Groups and Sessions". The Design and Implementation of the FreeBSD Operating System. Addison Wesley. ISBN 0201702452.
{{cite book}}
: Check date values in:|year=
(help); External link in
(help); Unknown parameter|chapterurl=
|chapterurl=
ignored (|chapter-url=
suggested) (help)CS1 maint: year (link)