Child process


A child process in computing is a process created by another 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 and the spawn.

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 form of the IBM OS/360 operating system, which introduced sub-tasking. The current form in Unix draws on Multics, while the Windows NT form draws on VAX/VMS, from RSX-11.

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 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 is started by the kernel at booting time and never terminates ; 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.

Children created by spawn

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. 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, 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. 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.