An address space with one or more threads executing within that address space, and the required system resources for those threads.

<small>Note: Many of the system resources defined by POSIX.1-2008 are shared among all of the threads within a process. These include the process ID, the parent process ID, process group ID, session membership, real, effective, and saved set-user-ID, real, effective, and saved set-group-ID, supplementary group IDs, current working directory, root directory, file mode creation mask, and file descriptors.</small>

A live process (see Section 3.210) or a zombie process (see Section 3.447). The lifetime of a process is described in Section 3.298.

The period of time that begins when a process is created and ends when its process ID is returned to the system. After a process is created by fork(), posix_spawn(), or posix_spawnp(), it is considered active. At least one thread of control and address space exist until it terminates. It then enters an inactive state where certain resources may be returned to the system, although some resources, such as the process ID, are still in use. When another process executes a wait(), waitid(), or waitpid() function for an inactive process, the remaining resources are returned to the system. The last resource to be returned to the system is the process ID. At this time, the lifetime of the process ends.

<small>Note: The fork(), posix_spawn(), posix_spawnp(), wait(), waitid(), and waitpid() functions are defined in detail in the System Interfaces volume of POSIX.1-2008.</small>

The period of time that begins when a process is created and ends when its process ID is returned to the system.

See also Live Process in Section 3.210, Process Termination in Section 3.300, and Zombie Process in Section 3.447.

<small>Note: Process creation is defined in detail in the descriptions of the fork(), posix_spawn(), and posix_spawnp() functions in the System Interfaces volume of POSIX.1-2008.</small>

<small>Note: The _exit(), _Exit(), abort(), and exit() functions are defined in detail in the System Interfaces volume of POSIX.1-2008.</small>

<small>Note: The consequences of process termination can be found in the description of the _Exit() function in the System Interfaces volume of POSIX.1-2008. The _exit(), _Exit(), abort(), and exit() functions are defined in detail in the System Interfaces volume of POSIX.1-2008.</small>

A process that has terminated and that is deleted when its exit status has been reported to another process which is waiting for that process to terminate.

The remains of a live process (see Section 3.210) after it terminates (see Section 3.300) and before its status information (see XSH Section 2.13) is consumed by its parent process.

2.13 Status Information

Status information is data associated with a process detailing a change in the state of the process. It shall consist of:

• The state the process transitioned into ('stopped', 'continued', or 'terminated').
• The information necessary to populate the siginfo_t structure provided by waitid().
• If the new state is 'terminated':
  • The low-order 8 bits of the status argument that the process passed to _Exit(), _exit(), or exit(), or the low-order 8 bits of the value the process returned from main().
  • Whether the process terminated due to the receipt of a signal that was not caught, and if so, the number of the signal that caused the termination of the process.
• If the new state is 'stopped':
  • The number of the signal that caused the process to stop.

A process might not have any status information (such as immediately after a process has started).

Status information shall be generated when a process stops, continues, or terminates except in the following case:

• If the parent process sets the action for the SIGCHLD signal to SIG_IGN, or if the parent sets the SA_NOCLDWAIT flag for the SIGCHLD signal action, process termination shall not generate new status information but shall cause any existing status information for the process to be discarded.

If new status information is generated, and the process already had status information, the existing status information shall be replaced with the new status information.

Only the process's parent process can obtain the process's status information. The parent obtains a child's status information by calling wait(), waitid(), or waitpid().

Except when waitid() is called with the WNOWAIT flag set in the options argument, the status information made available to a wait function shall be consumed (discarded) by that wait function; no two calls to wait(), waitid() (without WNOWAIT), or waitpid() shall obtain the same status information.

When status information becomes available to the parent process and more than one thread in the parent process is waiting for the status information (blocked in a call to wait(), waitid(), or waitpid() with arguments that would match the status information):

• If none of those threads is in a call to waitid() with the WNOWAIT flag set in the options argument, the thread that obtains the status information is unspecified.
• Otherwise (at least one of the threads is in a call to waitid() with the WNOWAIT flag set), the thread or threads that obtain the status information is unspecified except that at least one of those threads shall obtain the status information and at most one of those threads that are not calling waitid() with the WNOWAIT flag set shall obtain it.

[CX]SA_NOCLDWAIT Causes implementations not to create zombie processes on child death.[/CX]

[XSI]SA_NOCLDWAIT Causes implementations not to create zombie processes or status information on child termination. See sigaction(), page 1932.[/XSI]

If a process sets the action for the SIGCHLD signal to SIG_IGN, the behavior is unspecified, [XSI]except as specified below.

If the action for the SIGCHLD signal is set to SIG_IGN, child processes of the calling processes shall not be transformed into zombie processes when they terminate. If the calling process subsequently waits for its children, and the process has no unwaited-for children that were transformed into zombie processes, it shall block until all of its children terminate, and wait(), waitid(), and waitpid() shall fail and set errno to [ECHILD].[/XSI]

If a process sets the action for the SIGCHLD signal to SIG_IGN, the behavior is unspecified[XSI], except as specified under "Consequences of Process Termination" in the description of the _Exit() function on page 549[/XSI].

• If the parent process of the calling process is executing a wait(), waitid(), or waitpid(), [XSI]and has neither set its SA_NOCLDWAIT flag nor set SIGCHLD to SIG_IGN,[/XSI] it shall be notified of termination of the calling process and the child's status shall be made available to it. If the parent is not waiting, the child's status shall be made available to it when the parent subsequently executes wait(), waitid(), or waitpid().
• If the parent process of the calling process is not executing a wait(), waitid(), or waitpid(), [XSI]and has neither set its SA_NOCLDWAIT flag nor set SIGCHLD to SIG_IGN,[/XSI] the calling process shall be transformed into a zombie process. A zombie process is an inactive process and it shall be deleted at some later time when its parent process executes wait(), waitid(), or waitpid().
• Termination of a process does not directly terminate its children. The sending of a SIGHUP signal as described below indirectly terminates children in some circumstances.
• Either:
  
  If the implementation supports the SIGCHLD signal, a SIGCHLD shall be sent to the parent process.
  
  Or:
  
  [XSI]If the parent process has set its SA_NOCLDWAIT flag, or set SIGCHLD to SIG_IGN, the status shall be discarded, and the lifetime of the calling process shall end immediately. If SA_NOCLDWAIT is set, it is implementation-defined whether a SIGCHLD signal is sent to the parent process.[/XSI]

• [XSI]If the parent process of the calling process has set its SA_NOCLDWAIT flag or has set the action for the SIGCHLD signal to SIG_IGN:
  • The process's status information (see XSH Section 2.13), if any, shall be discarded.
  • The lifetime of the calling process shall end immediately. If SA_NOCLDWAIT is set, it is implementation-defined whether a SIGCHLD signal is sent to the parent process.
  • If a thread in the parent process of the calling process is blocked in wait(), waitpid(), or waitid(), and the parent process has no remaining child processes in the set of waited-for children, the wait(), waitid(), or waitpid() function shall fail and set errno to [ECHILD].
  Otherwise:[/XSI]
  • Status information (see XSH Section 2.13) shall be generated.
  • The calling process shall be transformed into a zombie process. Its status information shall be made available to the parent process until the process's lifetime ends.
  • The process's lifetime shall end once its parent obtains the process's status information via a currently-blocked or future call to wait(), waitid() (without WNOWAIT), or waitpid().
  • If one or more threads in the parent process of the calling process is blocked in a call to wait(), waitid(), or waitpid() awaiting termination of the process, one (or, if any are calling waitid() with WNOWAIT, possibly more) of these threads shall obtain the process's status information as specified in XSH Section 2.13 and become unblocked.
  • A SIGCHLD shall be sent to the parent process.
• Termination of a process does not directly terminate its children. The sending of a SIGHUP signal as described below indirectly terminates children in some circumstances.

SA_NOCLDWAIT: If set, and sig equals SIGCHLD, child processes of the calling processes shall not be transformed into zombie processes when they terminate. If the calling process subsequently waits for its children, and the process has no unwaited-for children that were transformed into zombie processes, it shall block until all of its children terminate, and wait(), waitid(), and waitpid() shall fail and set errno to [ECHILD]. Otherwise, terminating child processes shall be transformed into zombie processes, unless SIGCHLD is set to SIG_IGN.

[XSI]SA_NOCLDWAIT: If sig does not equal SIGCHLD, the behavior is unspecified. Otherwise, the behavior of the SA_NOCLDWAIT flag is as specified under "Consequences of Process Termination" in the description of the _Exit() function on page 549.[/XSI]

The wait() and waitpid() functions shall obtain status information pertaining to one of the caller's child processes. Various options permit status information to be obtained for child processes that have terminated or stopped. If status information is available for two or more child processes, the order in which their status is reported is unspecified.

The wait() function shall suspend execution of the calling thread until status information for one of the terminated child processes of the calling process is available, or until delivery of a signal whose action is either to execute a signal-catching function or to terminate the process. If more than one thread is suspended in wait() or waitpid() awaiting termination of the same process, exactly one thread shall return the process status at the time of the target process termination. If status information is available prior to the call to wait(), return shall be immediate.

The wait() and waitpid() functions shall obtain status information (see XSH Section 2.13) pertaining to one of the caller's child processes. The wait() function obtains status information for process termination from any child process. The waitpid() function obtains status information for process termination, and optionally process stop and/or continue, from a specified subset of the child processes.

The wait() function shall cause the calling thread to become blocked until status information generated by child process termination is made available to the thread, or until delivery of a signal whose action is either to execute a signal-catching function or to terminate the process, or an error occurs. If termination status information is available prior to the call to wait(), return shall be immediate. If termination status information is available for two or more child processes, the order in which their status is reported is unspecified.

As described in XSH Section 2.13, the wait() and waitpid() functions consume the status information they obtain.

The behavior when multiple threads are blocked in wait(), waitid(), or waitpid() is described in XSH Section 2.13.

[XSI]If the calling process has SA_NOCLDWAIT set or has SIGCHLD set to SIG_IGN, and the process has no unwaited-for children that were transformed into zombie processes, the calling thread shall block until all of the children of the process containing the calling thread terminate, and wait() and waitpid() shall fail and set errno to [ECHILD].[/XSI]

[XSI]As specified under "Consequences of Process Termination" in the description of the _Exit() function on page 549, if the calling process has SA_NOCLDWAIT set or has SIGCHLD set to SIG_IGN, then the termination of a child process will not cause status information to become available to a thread blocked in wait(), waitid(), or waitpid(). Thus, a thread blocked in one of the wait functions will remain blocked unless some other condition causes the thread to resume execution (such as an [ECHILD] failure due to no remaining children in the set of waited-for children).[/XSI]

The waitid() function shall suspend the calling thread until one child of the process containing the calling thread changes state. It records the current state of a child in the structure pointed to by infop. The fields of the structure pointed to by infop are filled in as described for the SIGCHLD signal in <signal.h>. If a child process changed state prior to the call to waitid(), waitid() shall return immediately. If more than one thread is suspended in wait(), waitid(), or waitpid() waiting for termination of the same process, exactly one thread shall return the process status at the time of the target process termination.

The waitid() function shall obtain status information (see XSH Section 2.13) pertaining to termination, stop, and/or continue events in one of the caller's child processes.

The waitid() function shall cause the calling thread to become blocked until an error occurs or status information becomes available to the calling thread that satisfies all of the following properties ("matching status information"):

• The status information is from one of the child processes in the set of child processes specified by the idtype and id arguments.
• The state change in the status information matches one of the state change flags set in the options argument.

If matching status information is available prior to the call to waitid(), return shall be immediate. If matching status information is available for two or more child processes, the order in which their status is reported is unspecified.

As described in XSH Section 2.13, the waitid() function consumes the status information it obtains unless the WNOWAIT flag is set in the options argument.

The behavior when multiple threads are blocked in wait(), waitid(), or waitpid() is described in XSH Section 2.13.

The waitid() function shall record the obtained status information in the structure pointed to by infop. The fields of the structure pointed to by infop shall be filled in as described under "Pointer to a Function" in Section 2.4.3 on page 492.

[XSI]As specified under "Consequences of Process Termination" in the description of the _Exit() function on page 549, if the calling process has SA_NOCLDWAIT set or has SIGCHLD set to SIG_IGN, then the termination of a child process will not cause status information to become available to a thread blocked in wait(), waitid(), or waitpid(). Thus, a thread blocked in one of the wait functions will remain blocked unless some other condition causes the thread to resume execution (such as an [ECHILD] failure due to no remaining children in the set of waited-for children).[/XSI]

An address space with one or more threads executing within that address space, and the required system resources for those threads.

<small>Note: Many of the system resources defined by POSIX.1-2008 are shared among all of the threads within a process. These include the process ID, the parent process ID, process group ID, session membership, real, effective, and saved set-user-ID, real, effective, and saved set-group-ID, supplementary group IDs, current working directory, root directory, file mode creation mask, and file descriptors.</small>

A live process (see Section 3.210) or a zombie process (see Section 3.447). The lifetime of a process is described in Section 3.298.

The period of time that begins when a process is created and ends when its process ID is returned to the system. After a process is created by fork(), posix_spawn(), or posix_spawnp(), it is considered active. At least one thread of control and address space exist until it terminates. It then enters an inactive state where certain resources may be returned to the system, although some resources, such as the process ID, are still in use. When another process executes a wait(), waitid(), or waitpid() function for an inactive process, the remaining resources are returned to the system. The last resource to be returned to the system is the process ID. At this time, the lifetime of the process ends.

<small>Note: The fork(), posix_spawn(), posix_spawnp(), wait(), waitid(), and waitpid() functions are defined in detail in the System Interfaces volume of POSIX.1-2008.</small>

The period of time that begins when a process is created and ends when its process ID is returned to the system.

See also Live Process in Section 3.210, Process Termination in Section 3.300, and Zombie Process in Section 3.447.

<small>Note: Process creation is defined in detail in the descriptions of the fork(), posix_spawn(), and posix_spawnp() functions in the System Interfaces volume of POSIX.1-2008.</small>

<small>Note: The _exit(), _Exit(), abort(), and exit() functions are defined in detail in the System Interfaces volume of POSIX.1-2008.</small>

<small>Note: The consequences of process termination can be found in the description of the _Exit() function in the System Interfaces volume of POSIX.1-2008. The _exit(), _Exit(), abort(), and exit() functions are defined in detail in the System Interfaces volume of POSIX.1-2008.</small>

A process that has terminated and that is deleted when its exit status has been reported to another process which is waiting for that process to terminate.

The remains of a live process (see Section 3.210) after it terminates (see Section 3.300) and before its status information (see XSH Section 2.13) is consumed by its parent process.

2.13 Status Information

Status information is data associated with a process detailing a change in the state of the process. It shall consist of:

• The state the process transitioned into ('stopped', 'continued', or 'terminated').
• The information necessary to populate the siginfo_t structure provided by waitid().
• If the new state is 'terminated':
  • The low-order 8 bits of the status argument that the process passed to _Exit(), _exit(), or exit(), or the low-order 8 bits of the value the process returned from main(). Note that these 8 bits are part of the complete value that is used to set the si_status member of the siginfo_t structure provided by waitid().
  • Whether the process terminated due to the receipt of a signal that was not caught, and if so, the number of the signal that caused the termination of the process.
• If the new state is 'stopped':
  • The number of the signal that caused the process to stop.

A process might not have any status information (such as immediately after a process has started).

Status information for a process shall be generated (made available to the parent process) when the process stops, continues, or terminates except in the following case:

• If the parent process sets the action for the SIGCHLD signal to SIG_IGN, or if the parent sets the SA_NOCLDWAIT flag for the SIGCHLD signal action, process termination shall not generate new status information but shall cause any existing status information for the process to be discarded.

If new status information is generated, and the process already had status information, the existing status information shall be discarded and replaced with the new status information.

Only the process's parent process can obtain the process's status information. The parent obtains a child's status information by calling wait(), waitid(), or waitpid().

Except when waitid() is called with the WNOWAIT flag set in the options argument, the status information obtained by a wait function shall be consumed (discarded) by that wait function; no two calls to wait(), waitid() (without WNOWAIT), or waitpid() shall obtain the same status information.

When status information becomes available to the parent process and more than one thread in the parent process is waiting for the status information (blocked in a call to wait(), waitid(), or waitpid() with arguments that would match the status information):

• If none of the matching threads is in a call to waitid() with the WNOWAIT flag set in the options argument, the thread that obtains the status information is unspecified.
• Otherwise (at least one of the matching threads is in a call to waitid() with the WNOWAIT flag set), the matching thread or threads that obtain the status information is unspecified except that at least one of the matching threads shall obtain the status information and at most one of the matching threads that are not calling waitid() with the WNOWAIT flag set shall obtain it.

[CX]SA_NOCLDWAIT Causes implementations not to create zombie processes on child death.[/CX]

[XSI]SA_NOCLDWAIT Causes implementations not to create zombie processes or status information on child termination. See sigaction(), page 1932.[/XSI]

If a process sets the action for the SIGCHLD signal to SIG_IGN, the behavior is unspecified, [XSI]except as specified below.

If the action for the SIGCHLD signal is set to SIG_IGN, child processes of the calling processes shall not be transformed into zombie processes when they terminate. If the calling process subsequently waits for its children, and the process has no unwaited-for children that were transformed into zombie processes, it shall block until all of its children terminate, and wait(), waitid(), and waitpid() shall fail and set errno to [ECHILD].[/XSI]

If a process sets the action for the SIGCHLD signal to SIG_IGN, the behavior is unspecified[XSI], except as specified under "Consequences of Process Termination" in the description of the _Exit() function on page 549[/XSI].

• If the parent process of the calling process is executing a wait(), waitid(), or waitpid(), [XSI]and has neither set its SA_NOCLDWAIT flag nor set SIGCHLD to SIG_IGN,[/XSI] it shall be notified of termination of the calling process and the child's status shall be made available to it. If the parent is not waiting, the child's status shall be made available to it when the parent subsequently executes wait(), waitid(), or waitpid().
• If the parent process of the calling process is not executing a wait(), waitid(), or waitpid(), [XSI]and has neither set its SA_NOCLDWAIT flag nor set SIGCHLD to SIG_IGN,[/XSI] the calling process shall be transformed into a zombie process. A zombie process is an inactive process and it shall be deleted at some later time when its parent process executes wait(), waitid(), or waitpid().
• Termination of a process does not directly terminate its children. The sending of a SIGHUP signal as described below indirectly terminates children in some circumstances.
• Either:
  
  If the implementation supports the SIGCHLD signal, a SIGCHLD shall be sent to the parent process.
  
  Or:
  
  [XSI]If the parent process has set its SA_NOCLDWAIT flag, or set SIGCHLD to SIG_IGN, the status shall be discarded, and the lifetime of the calling process shall end immediately. If SA_NOCLDWAIT is set, it is implementation-defined whether a SIGCHLD signal is sent to the parent process.[/XSI]

• [XSI]If the parent process of the calling process has set its SA_NOCLDWAIT flag or has set the action for the SIGCHLD signal to SIG_IGN:
  • The process's status information (see XSH Section 2.13), if any, shall be discarded.
  • The lifetime of the calling process shall end immediately. If SA_NOCLDWAIT is set, it is implementation-defined whether a SIGCHLD signal is sent to the parent process.
  • If a thread in the parent process of the calling process is blocked in wait(), waitpid(), or waitid(), and the parent process has no remaining child processes in the set of waited-for children, the wait(), waitid(), or waitpid() function shall fail and set errno to [ECHILD].
  Otherwise:[/XSI]
  • Status information (see XSH Section 2.13) shall be generated.
  • The calling process shall be transformed into a zombie process. Its status information shall be made available to the parent process until the process's lifetime ends.
  • The process's lifetime shall end once its parent obtains the process's status information via a currently-blocked or future call to wait(), waitid() (without WNOWAIT), or waitpid().
  • If one or more threads in the parent process of the calling process is blocked in a call to wait(), waitid(), or waitpid() awaiting termination of the process, one (or, if any are calling waitid() with WNOWAIT, possibly more) of these threads shall obtain the process's status information as specified in XSH Section 2.13 and become unblocked.
  • A SIGCHLD shall be sent to the parent process.
• Termination of a process does not directly terminate its children. The sending of a SIGHUP signal as described below indirectly terminates children in some circumstances.

SA_NOCLDWAIT: If set, and sig equals SIGCHLD, child processes of the calling processes shall not be transformed into zombie processes when they terminate. If the calling process subsequently waits for its children, and the process has no unwaited-for children that were transformed into zombie processes, it shall block until all of its children terminate, and wait(), waitid(), and waitpid() shall fail and set errno to [ECHILD]. Otherwise, terminating child processes shall be transformed into zombie processes, unless SIGCHLD is set to SIG_IGN.

[XSI]SA_NOCLDWAIT: If sig does not equal SIGCHLD, the behavior is unspecified. Otherwise, the behavior of the SA_NOCLDWAIT flag is as specified under "Consequences of Process Termination" in the description of the _Exit() function on page 549.[/XSI]

The wait() and waitpid() functions shall obtain status information pertaining to one of the caller's child processes. Various options permit status information to be obtained for child processes that have terminated or stopped. If status information is available for two or more child processes, the order in which their status is reported is unspecified.

The wait() function shall suspend execution of the calling thread until status information for one of the terminated child processes of the calling process is available, or until delivery of a signal whose action is either to execute a signal-catching function or to terminate the process. If more than one thread is suspended in wait() or waitpid() awaiting termination of the same process, exactly one thread shall return the process status at the time of the target process termination. If status information is available prior to the call to wait(), return shall be immediate.

The wait() and waitpid() functions shall obtain status information (see XSH Section 2.13) pertaining to one of the caller's child processes. The wait() function obtains status information for process termination from any child process. The waitpid() function obtains status information for process termination, and optionally process stop and/or continue, from a specified subset of the child processes.

The wait() function shall cause the calling thread to become blocked until status information generated by child process termination is made available to the thread, or until delivery of a signal whose action is either to execute a signal-catching function or to terminate the process, or an error occurs. If termination status information is available prior to the call to wait(), return shall be immediate. If termination status information is available for two or more child processes, the order in which their status is reported is unspecified.

As described in XSH Section 2.13, the wait() and waitpid() functions consume the status information they obtain.

The behavior when multiple threads are blocked in wait(), waitid(), or waitpid() is described in XSH Section 2.13.

[XSI]If the calling process has SA_NOCLDWAIT set or has SIGCHLD set to SIG_IGN, and the process has no unwaited-for children that were transformed into zombie processes, the calling thread shall block until all of the children of the process containing the calling thread terminate, and wait() and waitpid() shall fail and set errno to [ECHILD].[/XSI]

[XSI]As specified under "Consequences of Process Termination" in the description of the _Exit() function on page 549, if the calling process has SA_NOCLDWAIT set or has SIGCHLD set to SIG_IGN, then the termination of a child process will not cause status information to become available to a thread blocked in wait(), waitid(), or waitpid(). Thus, a thread blocked in one of the wait functions will remain blocked unless some other condition causes the thread to resume execution (such as an [ECHILD] failure due to no remaining children in the set of waited-for children).[/XSI]

The waitid() function shall suspend the calling thread until one child of the process containing the calling thread changes state. It records the current state of a child in the structure pointed to by infop. The fields of the structure pointed to by infop are filled in as described for the SIGCHLD signal in <signal.h>. If a child process changed state prior to the call to waitid(), waitid() shall return immediately. If more than one thread is suspended in wait(), waitid(), or waitpid() waiting for termination of the same process, exactly one thread shall return the process status at the time of the target process termination.

The waitid() function shall obtain status information (see XSH Section 2.13) pertaining to termination, stop, and/or continue events in one of the caller's child processes.

The waitid() function shall cause the calling thread to become blocked until an error occurs or status information becomes available to the calling thread that satisfies all of the following properties ("matching status information"):

• The status information is from one of the child processes in the set of child processes specified by the idtype and id arguments.
• The state change in the status information matches one of the state change flags set in the options argument.

If matching status information is available prior to the call to waitid(), return shall be immediate. If matching status information is available for two or more child processes, the order in which their status is reported is unspecified.

As described in XSH Section 2.13, the waitid() function consumes the status information it obtains unless the WNOWAIT flag is set in the options argument.

The behavior when multiple threads are blocked in wait(), waitid(), or waitpid() is described in XSH Section 2.13.

The waitid() function shall record the obtained status information in the structure pointed to by infop. The fields of the structure pointed to by infop shall be filled in as described under "Pointer to a Function" in Section 2.4.3 on page 492.

[XSI]As specified under "Consequences of Process Termination" in the description of the _Exit() function on page 549, if the calling process has SA_NOCLDWAIT set or has SIGCHLD set to SIG_IGN, then the termination of a child process will not cause status information to become available to a thread blocked in wait(), waitid(), or waitpid(). Thus, a thread blocked in one of the wait functions will remain blocked unless some other condition causes the thread to resume execution (such as an [ECHILD] failure due to no remaining children in the set of waited-for children).[/XSI]

B.2.13 Status Information

POSIX.1-2008 does not require all matching WNOWAIT threads (threads in a matching call to waitid() with the WNOWAIT flag set) to obtain a child's status information because the status information might be discarded (consumed or replaced) before one of the matching WNOWAIT threads is scheduled. If the status information is not discarded, it will remain available, so all of the matching WNOWAIT threads will (eventually) obtain the status information.