 |
This article needs additional citations for verification. Please help improve this articlebyadding citations to reliable sources. Unsourced material may be challenged and removed.
Find sources: "Wait" system call – news · newspapers · books · scholar · JSTOR (March 2007) (Learn how and when to remove this message) |
Incomputer operating systems, a process (ortask) may wait for another process to complete its execution. In most systems, a parent process can create an independently executing child process. The parent process may then issue a wait system call, which suspends the execution of the parent process while the child executes. When the child process terminates, it returns an exit status to the operating system, which is then returned to the waiting parent process. The parent process then resumes execution.[1]
Modern operating systems also provide system calls that allow a process's thread to create other threads and wait for them to terminate ("join" them) in a similar fashion.
An operating system may provide variations of the wait call that allow a process to wait for any of its child processes to exit, or to wait for a single specific child process (identified by its process ID) to exit.
Some operating systems issue a signal (SIGCHLD) to the parent process when a child process terminates, notifying the parent process and allowing it to retrieve the child process's exit status.
The exit status returned by a child process typically indicates whether the process terminated normally or abnormally. For normal termination, this status also includes the exit code (usually an integer value) that the process returned to the system. During the first 20 years of UNIX, only the low 8 bits of the exit code have been available to the waiting parent. In 1989 with SVR4,[citation needed] a new call waitid has been introduced that returns all bits from the exit call in a structure called siginfo_t in the structure member si_status.[citation needed] Waitid is a mandatory part of the POSIX standard since 2001.
When a child process terminates, it becomes a zombie process, and continues to exist as an entry in the system process table even though it is no longer an actively executing program. Under normal operation it will typically be immediately waited on by its parent, and then reaped by the system, reclaiming the resource (the process table entry). If a child is not waited on by its parent, it continues to consume this resource indefinitely, and thus is a resource leak. Such situations are typically handled with a special "reaper" process[citation needed] that locates zombies and retrieves their exit status, allowing the operating system to then deallocate their resources.
Conversely, a child process whose parent process terminates before it does becomes an orphan process. Such situations are typically handled with a special "root" (or "init") process, which is assigned as the new parent of a process when its parent process exits. This special process detects when an orphan process terminates and then retrieves its exit status, allowing the system to deallocate the terminated child process.
If a child process receives a signal, a waiting parent will then continue execution leaving an orphan process behind.[citation needed] Hence it is sometimes needed to check the argument set by wait, waitpid or waitid and, in the case that WIFSIGNALED is true, wait for the child process again to deallocate resources.[citation needed]
