A child process in computing is a process created by another process (the parent process). This technique pertains to multitasking operating systems, and is sometimes called a subprocess or traditionally a subtask.
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).
History
editChild processes date to the late 1960s, with an early form in later revisions of the Multiprogramming with a Fixed number of Tasks Version II (MFT-II) form of the IBM OS/360 operating system, which introduced sub-tasking (see task). The current form in Unix draws on Multics (1969), while the Windows NT form draws on OpenVMS (1978), from RSX-11 (1972).
Children created by fork
editA 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.[1]
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.[2]
Children created by spawn
editThis section needs expansion. You can help by adding to it. (February 2014) |
End of life
editWhen 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.[3] 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[4]), 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.[5] 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.[6]
See also
editReferences
edit- ^ This article is based on material taken from Child+process at 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.
- ^ – Base Definitions Reference, The Single UNIX Specification, Version 4 from The Open Group
- ^ : wait for process to change state – Linux Programmer's Manual – System Calls
- ^ "The Linux kernel: Signals". Win.tue.nl. Retrieved 2014-04-30.
- ^ [1] Archived September 29, 2011, at the Wayback Machine
- ^ : examine and change a signal action – Linux Programmer's Manual – System Calls