Editing Child process

{{Short description|Computing process created by another process}}
A '''child process''' (CP) in computing is a [[process (computing)|process]] created by another process (the [[parent process]]). This technique pertains to [[computer multitasking|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)|fork system call]] (preferred in [[Unix-like]] systems and the [[POSIX]] standard) and the [[spawn (computing)|spawn]] (preferred in the [[ntoskrnl.exe|modern (NT) kernel]] of [[Microsoft Windows]], as well as in some historical operating systems).

== History ==
Child 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 (computing)|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==
A child process inherits most of its [[Attribute (computing)|attribute]]s, such as [[file descriptor]]s, from its parent. In [[Unix]], a child process is typically created as a copy of the parent, using the [[fork (system call)|fork]] system call. The child process can then overlay itself with a different program (using {{mono|[[Exec (system call)|exec]]}}) as required.<ref>{{FOLDOC|Child+process}}</ref>

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 (operating system)|kernel]].  In some systems, including [[Linux kernel|Linux]]-based<!-- was an illiterate idiocy: Linux is not “Unix-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 (computing)|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 [[Unix signal|signal]] is sent to the parent of a child process when it [[exit (system call)|exit]]s, is interrupted, or resumes after being interrupted. By default the signal is simply ignored.<ref>{{man|bd|signal.h|SUS}}</ref>

==Children created by spawn==
{{main|Spawn (computing)}}
{{expand section|date=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 (system call)|wait]], the kernel retains some information about the process, such as its [[exit status]], to enable its parent to call ''wait'' later.<ref name="man2wait">{{man|2|wait|Linux|wait for process to change state}}</ref>  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<ref>{{cite web|url=http://www.win.tue.nl/~aeb/linux/lk/lk-5.html#ss5.5 |title=The Linux kernel: Signals |publisher=Win.tue.nl |date= |accessdate=2014-04-30}}</ref>), 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.<ref>[http://fuse4bsd.creo.hu/localcgi/man-cgi.cgi?signal+3] {{webarchive|url=https://web.archive.org/web/20110929182629/http://fuse4bsd.creo.hu/localcgi/man-cgi.cgi?signal+3|date=September 29, 2011}}</ref>  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.<ref>{{man|2|sigaction|Linux|examine and change a signal action}}</ref>

==See also==
* [[Exit (system call)|exit]]
* [[pstree]], for UNIX to find the child process (''pstree PID'', where PID is the process id of the process).

==References==
{{Reflist}}

==External links==
* {{man|1|pstree|die.net|print process trees}}

[[Category:Process (computing)]]