Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0000690 [1003.1(2013)/Issue7+TC1] System Interfaces Editorial Clarification Requested 2013-05-07 06:18 2019-06-10 08:55
Reporter tedu View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Closed  
Name Ted Unangst
Organization OpenBSD
User Reference
Section XSH 2.4.3, _Exit(), sigaction(), wait(), waitpid(), waitid(), wait()
Page Number 491, 549-550, 1932, 2203, 2212
Line Number 16773-16779, 19051-19072, 61931-61938, 69847-69856, 69881-69884, 70244-70250
Interp Status Approved
Final Accepted Text Note: 0001625
Summary 0000690: clarify behavior when calling waitpid with SA_NOCLDWAIT
Description From the description for waitpid:
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].

Similar text also appears in 2.4.3 Signal Actions of the base definitions.
The description for waitid (no p) doesn't indicate what its behavior is at all.

Please clarify the interaction when waitpid is called with a pid parameter that matches no children. As specified, I believe a strict interpretation requires the calling thread to block even when calling waitpid with an invalid pid. A more desirable interpretation might allow waitpid to return immediately if the pid doesn't exist or is not a child.

See attached source file.
Desired Action "In the case of waitpid, the calling thread shall block until no children match the pid parameter." ?
Tags tc2-2008
Attached Files c file icon w.c [^] (314 bytes) 2013-05-07 06:18

- Relationships
has duplicate 0000788Closed 1003.1(2013)/Issue7+TC1 Definition of Zombie Process unclear 
related to 0000594Closedajosey 1003.1(2008)/Issue 7 Clarify interaction of si_status and WIF* macros 
related to 0000792New 1003.1(2013)/Issue7+TC1 better definition of thread lifetime 
related to 0000947Appliedajosey 1003.1(2008)/Issue 7 Shell should not have $? == 0 for exit(256) 
related to 0000959Closedajosey 1003.1(2008)/Issue 7 struct siginfo member si_pid is marked "CX" but is mandatory for the non-CX waitid() 

-  Notes
(0001590)
philip-guenther (reporter)
2013-05-07 06:27

The interaction with WCONTINUED and WUNTRACED is also missing: waitpid() will return successfully if a child matches those conditions and the pid argument. Hmm, I guess those are affected by SA_NOCLDSTOP though.

Also: waitid() currently lacks any reference to SA_NOCLDWAIT, despite following the same rules as wait() and waitpid() on at least Solaris 10 and Linux 2.6.18.
(0001602)
rhansen (manager)
2013-05-12 19:28
edited on: 2013-05-23 15:50

Proposed changes:

After Issue7+TC1 XBD section 3.209 ("Link Count") page 66 line 1935, insert a new section 3.210 Live Process whose contents are copied from Issue7+TC1 XBD section 3.291 ("Process") page 80 lines 2269-2275 and renumber the subsequent sections.

At Issue7+TC1 XBD section 3.291 ("Process") page 80 lines 2269-2275, change:
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>
to:
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.
Note that the new text uses the adjusted section numbers.

At Issue7+TC1 XBD section 3.297 ("Process Lifetime") page 81 lines 2295-2304, change:
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>
to:
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>
Note that the new text uses the adjusted section numbers.

At Issue7+TC1 XBD section 3.299 ("Process Termination") page 81 lines 2318-2319, change:
<small>Note: The _exit(), _Exit(), abort(), and exit() functions are defined in detail in the System Interfaces volume of POSIX.1-2008.</small>
to:
<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>
At Issue7+TC1 XBD section 3.446 ("Zombie Process") page 105 lines 2871-2872, change:
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.
to:
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.
Note that the new text uses the adjusted section numbers.

After Issue7+TC1 XSH section 2.12 page 546 line 19012, insert:
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.
and renumber the subsequent sections.

At Issue7+TC1 XBD chapter 13 <signal.h> page 334 line 11158, change:
[CX]SA_NOCLDWAIT Causes implementations not to create zombie processes on child death.[/CX]
to:
[XSI]SA_NOCLDWAIT Causes implementations not to create zombie processes or status information on child termination. See sigaction(), page 1932.[/XSI]
Note the change from CX shading to XSI shading.

At Issue7+TC1 XSH section 2.4.3 page 491 lines 16773-16779, change:
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]
to:
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].
At Issue7+TC1 XSH chapter 3 (description of _Exit() and _exit(), "Consequences of Process Termination") pages 549-550 lines 19051-19072, after applying the changes in 0000594, change:
  • 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]
to:
  • [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.
At Issue7+TC1 XSH chapter 3 sigaction() description page 1932 lines 61931-61938, change:
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.
to:
[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]
Note the addition of XSI shading, which I believe was an omission.

At Issue7+TC1 XSH chapter 3 wait() and waitpid() description page 2203 lines 69847-69856, change:
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.
to:
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.
At Issue7+TC1 XSH chapter 3 wait() and waitpid() description page 2203 lines 69881-69884, remove:
[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]
After Issue7+TC1 XSH chapter 3 wait() and waitpid() application usage page 2208 after line 70110, insert:
[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]
At Issue7+TC1 XSH chapter 3 waitid() description page 2212 lines 70244-70250, change:
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.
to:
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.
After Issue7+TC1 XSH chapter 3 waitpid() application usage at page 2213 line 70293, insert:
[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]


(0001625)
geoffclare (manager)
2013-05-23 15:50
edited on: 2013-09-27 05:58

Interpretation response
------------------------
The standard is unclear on this issue, and no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor.

Rationale:
-------------
None.

Notes to the Editor (not part of this interpretation):
-------------------------------------------------------
Make the changes in Note: 0001855.

(0001812)
ajosey (manager)
2013-09-06 04:56

Interpretation Proposed 6 Sep 2013
(0001855)
rhansen (manager)
2013-09-27 04:21
edited on: 2013-09-27 04:23

Changes were suggested during the original review period (see <http://thread.gmane.org/gmane.comp.standards.posix.austin.general/8095 [^] >). The following are the new proposed changes, meant to supersede Note: 0001602:

After Issue7+TC1 XBD section 3.209 ("Link Count") page 66 line 1935, insert a new section 3.210 Live Process whose contents are copied from Issue7+TC1 XBD section 3.291 ("Process") page 80 lines 2269-2275 and renumber the subsequent sections.

At Issue7+TC1 XBD section 3.291 ("Process") page 80 lines 2269-2275, change:
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>
to:
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.
Note that the new text uses the adjusted section numbers.

At Issue7+TC1 XBD section 3.297 ("Process Lifetime") page 81 lines 2295-2304, change:
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>
to:
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>
Note that the new text uses the adjusted section numbers.

At Issue7+TC1 XBD section 3.299 ("Process Termination") page 81 lines 2318-2319, change:
<small>Note: The _exit(), _Exit(), abort(), and exit() functions are defined in detail in the System Interfaces volume of POSIX.1-2008.</small>
to:
<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>
At Issue7+TC1 XBD section 3.446 ("Zombie Process") page 105 lines 2871-2872, change:
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.
to:
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.
Note that the new text uses the adjusted section numbers.

After Issue7+TC1 XSH section 2.12 page 546 line 19012, insert:
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.
and renumber the subsequent sections.

At Issue7+TC1 XBD chapter 13 <signal.h> page 334 line 11158, change:
[CX]SA_NOCLDWAIT Causes implementations not to create zombie processes on child death.[/CX]
to:
[XSI]SA_NOCLDWAIT Causes implementations not to create zombie processes or status information on child termination. See sigaction(), page 1932.[/XSI]
Note the change from CX shading to XSI shading.

At Issue7+TC1 XSH section 2.4.3 page 491 lines 16773-16779, change:
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]
to:
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].
At Issue7+TC1 XSH chapter 3 (description of _Exit() and _exit(), "Consequences of Process Termination") pages 549-550 lines 19051-19072, after applying the changes in 0000594, change:
  • 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]
to:
  • [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.
At Issue7+TC1 XSH chapter 3 sigaction() description page 1932 lines 61931-61938, change:
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.
to:
[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]
Note the addition of XSI shading, which I believe was an omission.

At Issue7+TC1 XSH chapter 3 wait() and waitpid() description page 2203 lines 69847-69856, change:
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.
to:
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.
At Issue7+TC1 XSH chapter 3 wait() and waitpid() description page 2203 lines 69881-69884, remove:
[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]
After Issue7+TC1 XSH chapter 3 wait() and waitpid() application usage page 2208 after line 70110, insert:
[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]
At Issue7+TC1 XSH chapter 3 waitid() description page 2212 lines 70244-70250, change:
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.
to:
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.
After Issue7+TC1 XSH chapter 3 waitpid() application usage at page 2213 line 70293, insert:
[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]
After Issue7+TC1 XRAT section B.2.12.3 page 3649 line 124639, insert:
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.


(0001856)
ajosey (manager)
2013-09-27 13:09

Restarting the interpretation clock with a revised proposal.

Interpretation Proposed 27 Sep 2013
(0001947)
ajosey (manager)
2013-10-28 14:17

Interpretation approved 28 Oct 2013

- Issue History
Date Modified Username Field Change
2013-05-07 06:18 tedu New Issue
2013-05-07 06:18 tedu File Added: w.c
2013-05-07 06:18 tedu Name => Ted Unangst
2013-05-07 06:18 tedu Organization => OpenBSD
2013-05-07 06:18 tedu Section => waitpid
2013-05-07 06:27 philip-guenther Note Added: 0001590
2013-05-12 19:28 rhansen Note Added: 0001602
2013-05-12 19:50 rhansen Note Edited: 0001602
2013-05-13 15:32 eblake Relationship added related to 0000594
2013-05-15 03:01 rhansen Note Edited: 0001602
2013-05-16 15:17 rhansen Note Edited: 0001602
2013-05-16 15:26 rhansen Note Edited: 0001602
2013-05-16 15:32 rhansen Note Edited: 0001602
2013-05-16 15:35 rhansen Note Edited: 0001602
2013-05-16 15:38 rhansen Note Edited: 0001602
2013-05-17 16:35 rhansen Note Edited: 0001602
2013-05-17 16:36 rhansen Note Edited: 0001602
2013-05-17 16:36 rhansen Note Edited: 0001602
2013-05-17 16:38 rhansen Note Edited: 0001602
2013-05-17 16:39 rhansen Note Edited: 0001602
2013-05-17 16:44 rhansen Note Edited: 0001602
2013-05-17 16:45 rhansen Note Edited: 0001602
2013-05-17 20:23 rhansen Note Edited: 0001602
2013-05-17 20:29 rhansen Note Edited: 0001602
2013-05-17 21:22 rhansen Note Edited: 0001602
2013-05-17 21:30 rhansen Note Edited: 0001602
2013-05-17 21:35 rhansen Note Edited: 0001602
2013-05-17 21:36 rhansen Note Edited: 0001602
2013-05-17 21:37 rhansen Note Edited: 0001602
2013-05-17 21:39 rhansen Note Edited: 0001602
2013-05-17 21:41 rhansen Note Edited: 0001602
2013-05-17 21:42 rhansen Note Edited: 0001602
2013-05-17 22:05 rhansen Note Edited: 0001602
2013-05-17 22:15 rhansen Note Edited: 0001602
2013-05-17 22:19 rhansen Note Edited: 0001602
2013-05-17 22:23 rhansen Note Edited: 0001602
2013-05-17 22:24 rhansen Note Edited: 0001602
2013-05-17 22:29 rhansen Note Edited: 0001602
2013-05-20 13:30 rhansen Note Edited: 0001602
2013-05-20 20:09 rhansen Note Edited: 0001602
2013-05-20 20:12 rhansen Note Edited: 0001602
2013-05-20 20:16 rhansen Note Edited: 0001602
2013-05-20 20:23 rhansen Note Edited: 0001602
2013-05-20 21:10 rhansen Note Edited: 0001602
2013-05-23 15:31 rhansen Note Edited: 0001602
2013-05-23 15:42 rhansen Note Edited: 0001602
2013-05-23 15:48 rhansen Note Edited: 0001602
2013-05-23 15:50 rhansen Note Edited: 0001602
2013-05-23 15:50 geoffclare Note Added: 0001625
2013-05-23 15:57 geoffclare Interp Status => Pending
2013-05-23 15:57 geoffclare Final Accepted Text => Note: 0001625
2013-05-23 15:57 geoffclare Status New => Interpretation Required
2013-05-23 15:57 geoffclare Resolution Open => Accepted As Marked
2013-05-23 15:57 geoffclare Tag Attached: tc2-2008
2013-09-06 04:56 ajosey Interp Status Pending => Proposed
2013-09-06 04:56 ajosey Note Added: 0001812
2013-09-27 04:21 rhansen Note Added: 0001855
2013-09-27 04:23 rhansen Note Edited: 0001855
2013-09-27 05:58 Don Cragun Page Number => 491, 549-550, 1932, 2203, 2212
2013-09-27 05:58 Don Cragun Line Number => 16773-16779, 19051-19072, 61931-61938, 69847-69856, 69881-69884, 70244-70250
2013-09-27 05:58 Don Cragun Interp Status Proposed => Pending
2013-09-27 05:58 Don Cragun Note Edited: 0001625
2013-09-27 06:00 Don Cragun Section waitpid => XSH 2.4.3, _Exit(), sigaction(), wait(), waitpid(), waitid(), wait()
2013-09-27 13:09 ajosey Interp Status Pending => Proposed
2013-09-27 13:09 ajosey Note Added: 0001856
2013-10-28 14:17 ajosey Interp Status Proposed => Approved
2013-10-28 14:17 ajosey Note Added: 0001947
2013-11-08 10:35 geoffclare Relationship added has duplicate 0000788
2013-11-15 05:24 eblake Relationship added related to 0000792
2015-07-06 16:21 rhansen Relationship added related to 0000947
2015-07-10 21:39 rhansen Relationship added related to 0000959
2019-06-10 08:55 agadmin Status Interpretation Required => Closed


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker