Child process
A child process in computing is a process created by another process (the parent process). This technique pertains to multitasking operating systems. There are two major procedures for creating a child process: the fork system call (preferred in Unix-like systems and the POSIX standard) and the spawn (preferred in the modern (NT) kernel of Microsoft Windows, as well as in some historical operating systems).
Children created by fork
A child process inherits most of its attributes, such as file descriptors, from its parent. In Unix, a child process is typically created as a copy of the parent, using the fork system call. The child process can then overlay itself with a different program (using exec) as required.
Each process may create many child processes but will have at most one parent process; if a process does not have a parent this usually indicates that it was created directly by the kernel. In some systems, including Linux-based systems, the very first process (called init) is started by the kernel at booting time and never terminates (see Linux startup process); other parentless processes may be launched to carry out various daemon tasks in userspace. Another way for a process to end up without a parent is if its parent dies, leaving an orphan process; but in this case it will shortly be adopted by init.
The SIGCHLD signal is sent to the parent of a child process when it exits, is interrupted, or resumes after being interrupted. By default the signal is simply ignored.[1]
Children created by spawn
This section needs expansion. You can help by adding to it. (February 2014) |
End of life
When a child process terminates, some information is returned to the parent process.
When a child process terminates before the parent has called wait, the kernel retains some information about the process, such as its exit status, to enable its parent to call wait later.[2] Because the child is still consuming system resources but not executing it is known as a zombie process. The wait system call is commonly invoked in the SIGCHLD handler.
POSIX.1-2001 allows a parent process to elect for the kernel to automatically reap child processes that terminate by explicitly setting the disposition of SIGCHLD to SIG_IGN (although ignore is the default, automatic reaping only occurs if the disposition is set to ignore explicitly[3]), or by setting the SA_NOCLDWAIT flag for the SIGCHLD signal. Linux 2.6 kernels adhere to this behavior, and FreeBSD supports both of these methods since version 5.0.[4] However, because of historical differences between System V and BSD behaviors with regard to ignoring SIGCHLD, calling wait remains the most portable paradigm for cleaning up after forked child processes.[2][5]
See also
- Exit
- pstree, for UNIX to find the child process (pstree PID, where PID is the process id of the process).
References
- ^ The Single UNIX Specification, Version 4 from The Open Group : overview of signals – Base Definitions Reference,
- ^ a b The Single UNIX Specification, Version 4 from The Open Group : wait for process to change state – System Interfaces Reference,
- ^ http://www.win.tue.nl/~aeb/linux/lk/lk-5.html#ss5.5
- ^ http://fuse4bsd.creo.hu/localcgi/man-cgi.cgi?signal+3
- ^ The Single UNIX Specification, Version 4 from The Open Group : examine and change a signal action – System Interfaces Reference,
The Single UNIX Specification, Version 4 from The Open Group
: print process trees – Shell and Utilities Reference,Notes
This article is based on material taken from the Free On-line Dictionary of Computing prior to 1 November 2008 and incorporated under the "relicensing" terms of the GFDL, version 1.3 or later.