diff options
Diffstat (limited to 'man-pages-posix-2017/man3p/wait.3p')
| -rw-r--r-- | man-pages-posix-2017/man3p/wait.3p | 909 |
1 files changed, 909 insertions, 0 deletions
diff --git a/man-pages-posix-2017/man3p/wait.3p b/man-pages-posix-2017/man3p/wait.3p new file mode 100644 index 0000000..7f18dac --- /dev/null +++ b/man-pages-posix-2017/man3p/wait.3p @@ -0,0 +1,909 @@ +'\" et +.TH WAIT "3P" 2017 "IEEE/The Open Group" "POSIX Programmer's Manual" +.\" +.SH PROLOG +This manual page is part of the POSIX Programmer's Manual. +The Linux implementation of this interface may differ (consult +the corresponding Linux manual page for details of Linux behavior), +or the interface may not be implemented on Linux. +.\" +.SH NAME +wait, +waitpid +\(em wait for a child process to stop or terminate +.SH SYNOPSIS +.LP +.nf +#include <sys/wait.h> +.P +pid_t wait(int *\fIstat_loc\fP); +pid_t waitpid(pid_t \fIpid\fP, int *\fIstat_loc\fP, int \fIoptions\fP); +.fi +.SH DESCRIPTION +The +\fIwait\fR() +and +\fIwaitpid\fR() +functions shall obtain status information (see +.IR "Section 2.13" ", " "Status Information") +pertaining to one of the caller's child processes. The +\fIwait\fR() +function obtains status information for process termination from +any child process. The +\fIwaitpid\fR() +function obtains status information for process termination, and +optionally process stop and/or continue, from a specified subset of +the child processes. +.P +The +\fIwait\fR() +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 +\fIwait\fR(), +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. +.P +As described in +.IR "Section 2.13" ", " "Status Information", +the +\fIwait\fR() +and +\fIwaitpid\fR() +functions consume the status information they obtain. +.P +The behavior when multiple threads are blocked in +\fIwait\fR(), +\fIwaitid\fR(), +or +\fIwaitpid\fR() +is described in +.IR "Section 2.13" ", " "Status Information". +.P +The +\fIwaitpid\fR() +function shall be equivalent to +\fIwait\fR() +if the +.IR pid +argument is (\fBpid_t\fP)\-1 and the +.IR options +argument is 0. Otherwise, its behavior shall be modified by the values +of the +.IR pid +and +.IR options +arguments. +.P +The +.IR pid +argument specifies a set of child processes for which +.IR status +is requested. The +\fIwaitpid\fR() +function shall only return the status of a child process from this set: +.IP " *" 4 +If +.IR pid +is equal to (\fBpid_t\fP)\-1, +.IR status +is requested for any child process. In this respect, +\fIwaitpid\fR() +is then equivalent to +\fIwait\fR(). +.IP " *" 4 +If +.IR pid +is greater than 0, it specifies the process ID of a single child +process for which +.IR status +is requested. +.IP " *" 4 +If +.IR pid +is 0, +.IR status +is requested for any child process whose process group ID is equal to +that of the calling process. +.IP " *" 4 +If +.IR pid +is less than (\fBpid_t\fP)\-1, +.IR status +is requested for any child process whose process group ID is equal to +the absolute value of +.IR pid . +.P +The +.IR options +argument is constructed from the bitwise-inclusive OR of zero or more +of the following flags, defined in the +.IR <sys/wait.h> +header: +.IP WCONTINUED 12 +The +\fIwaitpid\fR() +function shall report the status of any continued child process +specified by +.IR pid +whose status has not been reported since it continued from a job +control stop. +.IP WNOHANG 12 +The +\fIwaitpid\fR() +function shall not suspend execution of the calling thread if +.IR status +is not immediately available for one of the child processes specified +by +.IR pid . +.IP WUNTRACED 12 +The status of any child processes specified by +.IR pid +that are stopped, and whose status has not yet been reported since they +stopped, shall also be reported to the requesting process. +.P +If +\fIwait\fR() +or +\fIwaitpid\fR() +return because the status of a child process is available, these +functions shall return a value equal to the process ID of the child +process. In this case, if the value of the argument +.IR stat_loc +is not a null pointer, information shall be stored in the location +pointed to by +.IR stat_loc . +The value stored at the location pointed to by +.IR stat_loc +shall be 0 if and only if the status returned is from a terminated +child process that terminated by one of the following means: +.IP " 1." 4 +The process returned 0 from +\fImain\fR(). +.IP " 2." 4 +The process called +\fI_exit\fR() +or +\fIexit\fR() +with a +.IR status +argument of 0. +.IP " 3." 4 +The process was terminated because the last thread in the process +terminated. +.P +Regardless of its value, this information may be +interpreted using the following macros, which are defined in +.IR <sys/wait.h> +and evaluate to integral expressions; the +.IR stat_val +argument is the integer value pointed to by +.IR stat_loc . +.IP "WIFEXITED(\fIstat_val\fP)" 6 +.br +Evaluates to a non-zero value if +.IR status +was returned for a child process that terminated normally. +.IP "WEXITSTATUS(\fIstat_val\fP)" 6 +.br +If the value of WIFEXITED(\fIstat_val\fP) is non-zero, this macro +evaluates to the low-order 8 bits of the +.IR status +argument that the child process passed to +\fI_exit\fR() +or +\fIexit\fR(), +or the value the child process returned from +\fImain\fR(). +.IP "WIFSIGNALED(\fIstat_val\fP)" 6 +.br +Evaluates to a non-zero value if +.IR status +was returned for a child process that terminated due to the receipt of +a signal that was not caught (see +.IR <signal.h> ). +.IP "WTERMSIG(\fIstat_val\fP)" 6 +.br +If the value of WIFSIGNALED(\fIstat_val\fP) is non-zero, this macro +evaluates to the number of the signal that caused the termination of +the child process. +.IP "WIFSTOPPED(\fIstat_val\fP)" 6 +.br +Evaluates to a non-zero value if +.IR status +was returned for a child process that is currently stopped. +.IP "WSTOPSIG(\fIstat_val\fP)" 6 +.br +If the value of WIFSTOPPED(\fIstat_val\fP) is non-zero, this macro +evaluates to the number of the signal that caused the child process to +stop. +.IP "WIFCONTINUED(\fIstat_val\fP)" 6 +.br +Evaluates to a non-zero value if +.IR status +was returned for a child process that has continued from a job control +stop. +.P +It is unspecified whether the +.IR status +value returned by calls to +\fIwait\fR() +or +\fIwaitpid\fR() +for processes created by +\fIposix_spawn\fR() +or +\fIposix_spawnp\fR() +can indicate a WIFSTOPPED(\fIstat_val\fP) before subsequent calls to +\fIwait\fR() +or +\fIwaitpid\fR() +indicate WIFEXITED(\fIstat_val\fP) as the result of an error detected +before the new process image starts executing. +.P +It is unspecified whether the +.IR status +value returned by calls to +\fIwait\fR() +or +\fIwaitpid\fR() +for processes created by +\fIposix_spawn\fR() +or +\fIposix_spawnp\fR() +can indicate a WIFSIGNALED(\fIstat_val\fP) if a signal is sent to the +parent's process group after +\fIposix_spawn\fR() +or +\fIposix_spawnp\fR() +is called. +.P +If the information pointed to by +.IR stat_loc +was stored by a call to +\fIwaitpid\fR() +that specified the WUNTRACED flag +and did not specify the WCONTINUED flag, +exactly one of the macros WIFEXITED(*\fIstat_loc\fR), +WIFSIGNALED(*\fIstat_loc\fR), and WIFSTOPPED(*\fIstat_loc\fR) +shall evaluate to a non-zero value. +.P +If the information pointed to by +.IR stat_loc +was stored by a call to +\fIwaitpid\fR() +that specified the WUNTRACED and WCONTINUED flags, exactly one +of the macros WIFEXITED(*\fIstat_loc\fR), +WIFSIGNALED(*\fIstat_loc\fR), WIFSTOPPED(*\fIstat_loc\fR), +and WIFCONTINUED(*\fIstat_loc\fR) shall evaluate to a non-zero value. +.P +If the information pointed to by +.IR stat_loc +was stored by a call to +\fIwaitpid\fR() +that did not specify the WUNTRACED +or WCONTINUED +flags, or by a call to the +\fIwait\fR() +function, exactly one of the macros WIFEXITED(*\fIstat_loc\fR) and +WIFSIGNALED(*\fIstat_loc\fR) shall evaluate to a non-zero value. +.P +If the information pointed to by +.IR stat_loc +was stored by a call to +\fIwaitpid\fR() +that did not specify the WUNTRACED flag and specified the WCONTINUED flag, +exactly one of the macros WIFEXITED(*\fIstat_loc\fR), +WIFSIGNALED(*\fIstat_loc\fR), and WIFCONTINUED(*\fIstat_loc\fR) +shall evaluate to a non-zero value. +.P +If _POSIX_REALTIME_SIGNALS is defined, and the implementation queues +the SIGCHLD signal, then if +\fIwait\fR() +or +\fIwaitpid\fR() +returns because the status of a child process is available, any pending +SIGCHLD signal associated with the process ID of the child process +shall be discarded. Any other pending SIGCHLD signals shall remain +pending. +.P +Otherwise, if SIGCHLD is blocked, if +\fIwait\fR() +or +\fIwaitpid\fR() +return because the status of a child process is available, any pending +SIGCHLD signal shall be cleared unless the status of another child +process is available. +.P +For all other conditions, it is unspecified whether child +.IR status +will be available when a SIGCHLD signal is delivered. +.P +There may be additional implementation-defined circumstances under +which +\fIwait\fR() +or +\fIwaitpid\fR() +report +.IR status . +This shall not occur unless the calling process or one of its child +processes explicitly makes use of a non-standard extension. In these +cases the interpretation of the reported +.IR status +is implementation-defined. +.P +If a parent process terminates without waiting for all of its child +processes to terminate, the remaining child processes shall be assigned +a new parent process ID corresponding to an implementation-defined +system process. +.SH "RETURN VALUE" +If +\fIwait\fR() +or +\fIwaitpid\fR() +returns because the status of a child process is available, these +functions shall return a value equal to the process ID of the child +process for which +.IR status +is reported. If +\fIwait\fR() +or +\fIwaitpid\fR() +returns due to the delivery of a signal to the calling process, \-1 +shall be returned and +.IR errno +set to +.BR [EINTR] . +If +\fIwaitpid\fR() +was invoked with WNOHANG set in +.IR options , +it has at least one child process specified by +.IR pid +for which +.IR status +is not available, and +.IR status +is not available for any process specified by +.IR pid , +0 is returned. Otherwise, \-1 shall be returned, and +.IR errno +set to indicate the error. +.SH ERRORS +The +\fIwait\fR() +function shall fail if: +.TP +.BR ECHILD +The calling process has no existing unwaited-for child processes. +.TP +.BR EINTR +The function was interrupted by a signal. The value of the location +pointed to by +.IR stat_loc +is undefined. +.P +The +\fIwaitpid\fR() +function shall fail if: +.TP +.BR ECHILD +The process specified by +.IR pid +does not exist or is not a child of the calling process, or the process +group specified by +.IR pid +does not exist or does not have any member process that is a child of +the calling process. +.TP +.BR EINTR +The function was interrupted by a signal. The value of the location +pointed to by +.IR stat_loc +is undefined. +.TP +.BR EINVAL +The +.IR options +argument is not valid. +.LP +.IR "The following sections are informative." +.SH EXAMPLES +.SS "Waiting for a Child Process and then Checking its Status" +.P +The following example demonstrates the use of +\fIwaitpid\fR(), +\fIfork\fR(), +and the macros used to interpret the status value returned by +\fIwaitpid\fR() +(and +\fIwait\fR()). +The code segment creates a child process which does some unspecified +work. Meanwhile the parent loops performing calls to +\fIwaitpid\fR() +to monitor the status of the child. The loop terminates when child +termination is detected. +.sp +.RS 4 +.nf + +#include <stdio.h> +#include <stdlib.h> +#include <unistd.h> +#include <sys/wait.h> +\&... +.P +pid_t child_pid, wpid; +int status; +.P +child_pid = fork(); +if (child_pid == -1) { /* fork() failed */ + perror("fork"); + exit(EXIT_FAILURE); +} +.P +if (child_pid == 0) { /* This is the child */ + /* Child does some work and then terminates */ + ... +.P +} else { /* This is the parent */ + do { + wpid = waitpid(child_pid, &status, WUNTRACED +#ifdef WCONTINUED /* Not all implementations support this */ + | WCONTINUED +#endif + ); + if (wpid == -1) { + perror("waitpid"); + exit(EXIT_FAILURE); + } +.P + if (WIFEXITED(status)) { + printf("child exited, status=%d\en", WEXITSTATUS(status)); +.P + } else if (WIFSIGNALED(status)) { + printf("child killed (signal %d)\en", WTERMSIG(status)); +.P + } else if (WIFSTOPPED(status)) { + printf("child stopped (signal %d)\en", WSTOPSIG(status)); +.P +#ifdef WIFCONTINUED /* Not all implementations support this */ + } else if (WIFCONTINUED(status)) { + printf("child continued\en"); +#endif + } else { /* Non-standard case -- may never happen */ + printf("Unexpected status (0x%x)\en", status); + } + } while (!WIFEXITED(status) && !WIFSIGNALED(status)); +} +.fi +.P +.RE +.SS "Waiting for a Child Process in a Signal Handler for SIGCHLD" +.P +The following example demonstrates how to use +\fIwaitpid\fR() +in a signal handler for SIGCHLD without passing \-1 as the +.IR pid +argument. (See the APPLICATION USAGE section below for the reasons +why passing a +.IR pid +of \-1 is not recommended.) The method used here relies on the +standard behavior of +\fIwaitpid\fR() +when SIGCHLD is blocked. On historical non-conforming systems, the +status of some child processes might not be reported. +.sp +.RS 4 +.nf + +#include <stdlib.h> +#include <stdio.h> +#include <signal.h> +#include <sys/types.h> +#include <sys/wait.h> +#include <unistd.h> +.P +#define CHILDREN 10 +.P +static void +handle_sigchld(int signum, siginfo_t *sinfo, void *unused) +{ + int sav_errno = errno; + int status; +.P + /* + * Obtain status information for the child which + * caused the SIGCHLD signal and write its exit code + * to stdout. + */ + if (sinfo->si_code != CLD_EXITED) + { + static char msg[] = "wrong si_code\en"; + write(2, msg, sizeof msg - 1); + } + else if (waitpid(sinfo->si_pid, &status, 0) =\|= -1) + { + static char msg[] = "waitpid() failed\en"; + write(2, msg, sizeof msg - 1); + } + else if (!WIFEXITED(status)) + { + static char msg[] = "WIFEXITED was false\en"; + write(2, msg, sizeof msg - 1); + } + else + { + int code = WEXITSTATUS(status); + char buf[2]; + buf[0] = \(aq0\(aq + code; + buf[1] = \(aq\en\(aq; + write(1, buf, 2); + } + errno = sav_errno; +} +.P +int +main(void) +{ + int i; + pid_t pid; + struct sigaction sa; +.P + sa.sa_flags = SA_SIGINFO; + sa.sa_sigaction = handle_sigchld; + sigemptyset(&sa.sa_mask); + if (sigaction(SIGCHLD, &sa, NULL) =\|= -1) + { + perror("sigaction"); + exit(EXIT_FAILURE); + } +.P + for (i = 0; i < CHILDREN; i++) + { + switch (pid = fork()) + { + case -1: + perror("fork"); + exit(EXIT_FAILURE); + case 0: + sleep(2); + _exit(i); + } + } +.P + /* Wait for all the SIGCHLD signals, then terminate on SIGALRM */ + alarm(3); + for (;;) + pause(); +.P + return 0; /* NOTREACHED */ +} +.fi +.P +.RE +.SH "APPLICATION USAGE" +Calls to +\fIwait\fR() +will collect information about any child process. This may result in +interactions with other interfaces that may be waiting for their own +children (such as by use of +\fIsystem\fR()). +For this and other reasons it is recommended that portable applications +not use +\fIwait\fR(), +but instead use +\fIwaitpid\fR(). +For these same reasons, the use of +\fIwaitpid\fR() +with a +.IR pid +argument of \-1, and the use of +\fIwaitid\fR() +with the +.IR idtype +argument set to P_ALL, are also not recommended for portable applications. +.P +As specified in +.IR "Consequences of Process Termination", +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 +\fIwait\fR(), +\fIwaitid\fR(), +or +\fIwaitpid\fR(). +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 +.BR [ECHILD] +failure due to no remaining children in the set of waited-for children). +.SH RATIONALE +A call to the +\fIwait\fR() +or +\fIwaitpid\fR() +function only returns +.IR status +on an immediate child process of the calling process; that is, a child +that was produced by a single +\fIfork\fR() +call (perhaps followed by an +.IR exec +or other function calls) from the parent. If a child produces +grandchildren by further use of +\fIfork\fR(), +none of those grandchildren nor any of their descendants affect the +behavior of a +\fIwait\fR() +from the original parent process. Nothing in this volume of POSIX.1\(hy2017 prevents an +implementation from providing extensions that permit a process to get +.IR status +from a grandchild or any other process, but a process that does not use +such extensions must be guaranteed to see +.IR status +from only its direct children. +.P +The +\fIwaitpid\fR() +function is provided for three reasons: +.IP " 1." 4 +To support job control +.IP " 2." 4 +To permit a non-blocking version of the +\fIwait\fR() +function +.IP " 3." 4 +To permit a library routine, such as +\fIsystem\fR() +or +\fIpclose\fR(), +to wait for its children without interfering with other terminated +children for which the process has not waited +.P +The first two of these facilities are based on the +.IR wait3 (\|) +function provided by 4.3 BSD. The function uses the +.IR options +argument, which is equivalent to an argument to +.IR wait3 (\|). +The WUNTRACED +flag is used only in conjunction with job control on systems supporting +job control. Its name comes from 4.3 BSD +and refers to the fact that there are two types of stopped processes in +that implementation: processes being traced via the +\fIptrace\fR() +debugging facility and (untraced) processes stopped by job control +signals. Since +\fIptrace\fR() +is not part of this volume of POSIX.1\(hy2017, only the second type is relevant. The name +WUNTRACED was retained because its usage is the same, even though the +name is not intuitively meaningful in this context. +.P +The third reason for the +\fIwaitpid\fR() +function is to permit independent sections of a process to spawn and +wait for children without interfering with each other. For example, +the following problem occurs in developing a portable shell, or command +interpreter: +.sp +.RS 4 +.nf + +stream = popen("/bin/true"); +(void) system("sleep 100"); +(void) pclose(stream); +.fi +.P +.RE +.P +On all historical implementations, the final +\fIpclose\fR() +fails to reap the +\fIwait\fR() +.IR status +of the +\fIpopen\fR(). +.P +The status values are retrieved by macros, rather than given as +specific bit encodings as they are in most historical implementations +(and thus expected by existing programs). This was necessary to +eliminate a limitation on the number of signals an implementation can +support that was inherent in the traditional encodings. This volume of POSIX.1\(hy2017 +does require that a +.IR status +value of zero corresponds to a process calling +.IR _exit (0), +as this is the most common encoding expected by existing programs. +Some of the macro names were adopted from 4.3 BSD. +.P +These macros syntactically operate on an arbitrary integer value. The +behavior is undefined unless that value is one stored by a successful +call to +\fIwait\fR() +or +\fIwaitpid\fR() +in the location pointed to by the +.IR stat_loc +argument. An early proposal attempted to make this clearer by specifying +each argument as *\fIstat_loc\fP rather than +.IR stat_val . +However, that did not follow the conventions of other specifications in +\&this volume of POSIX.1\(hy2017 or traditional usage. It also could have implied that the +argument to the macro must literally be *\fIstat_loc\fP; in fact, that +value can be stored or passed as an argument to other functions before +being interpreted by these macros. +.P +The extension that affects +\fIwait\fR() +and +\fIwaitpid\fR() +and is common in historical implementations is the +\fIptrace\fR() +function. It is called by a child process and causes that child to +stop and return a +.IR status +that appears identical to the +.IR status +indicated by WIFSTOPPED. +The +.IR status +of +\fIptrace\fR() +children is traditionally returned regardless of the WUNTRACED +flag (or by the +\fIwait\fR() +function). Most applications do not need to concern themselves with +such extensions because they have control over what extensions they or +their children use. However, applications, such as command +interpreters, that invoke arbitrary processes may see this behavior +when those arbitrary processes misuse such extensions. +.P +Implementations that support +.BR core +file creation or other implementation-defined actions on termination +of some processes traditionally provide a bit in the +.IR status +returned by +\fIwait\fR() +to indicate that such actions have occurred. +.P +Allowing the +\fIwait\fR() +family of functions to discard a pending SIGCHLD signal that is +associated with a successfully waited-for child process puts them into +the +\fIsigwait\fR() +and +\fIsigwaitinfo\fR() +category with respect to SIGCHLD. +.P +This definition allows implementations to treat a pending SIGCHLD +signal as accepted by the process in +\fIwait\fR(), +with the same meaning of ``accepted'' as when that word is applied to +the +\fIsigwait\fR() +family of functions. +.P +Allowing the +\fIwait\fR() +family of functions to behave this way permits an implementation to be +able to deal precisely with SIGCHLD signals. +.P +In particular, an implementation that does accept (discard) the SIGCHLD +signal can make the following guarantees regardless of the queuing +depth of signals in general (the list of waitable children can hold the +SIGCHLD queue): +.IP " 1." 4 +If a SIGCHLD signal handler is established via +\fIsigaction\fR() +without the SA_RESETHAND flag, SIGCHLD signals can be accurately +counted; that is, exactly one SIGCHLD signal will be delivered to or +accepted by the process for every child process that terminates. +.IP " 2." 4 +A single +\fIwait\fR() +issued from a SIGCHLD signal handler can be guaranteed to return +immediately with status information for a child process. +.IP " 3." 4 +When SA_SIGINFO is requested, the SIGCHLD signal handler can be +guaranteed to receive a non-null pointer to a +.BR siginfo_t +structure that describes a child process for which a wait via +\fIwaitpid\fR() +or +\fIwaitid\fR() +will not block or fail. +.IP " 4." 4 +The +\fIsystem\fR() +function will not cause the SIGCHLD handler of a process to be +called as a result of the +\fIfork\fR()/\c +.IR exec +executed within +\fIsystem\fR() +because +\fIsystem\fR() +will accept the SIGCHLD signal when it performs a +\fIwaitpid\fR() +for its child process. This is a desirable behavior of +\fIsystem\fR() +so that it can be used in a library without causing side-effects to the +application linked with the library. +.P +An implementation that does not permit the +\fIwait\fR() +family of functions to accept (discard) a pending SIGCHLD signal +associated with a successfully waited-for child, cannot make the +guarantees described above for the following reasons: +.IP "Guarantee #1" 6 +.br +Although it might be assumed that reliable queuing of all SIGCHLD +signals generated by the system can make this guarantee, the +counter-example is the case of a process that blocks SIGCHLD and +performs an indefinite loop of +\fIfork\fR()/\c +\fIwait\fR() +operations. If the implementation supports queued signals, then +eventually the system will run out of memory for the queue. The +guarantee cannot be made because there must be some limit to the depth +of queuing. +.IP "Guarantees #2 and #3" 6 +.br +These cannot be guaranteed unless the +\fIwait\fR() +family of functions accepts the SIGCHLD signal. Otherwise, a +\fIfork\fR()/\c +\fIwait\fR() +executed while SIGCHLD is blocked (as in the +\fIsystem\fR() +function) will result in an invocation of the handler when SIGCHLD is +unblocked, after the process has disappeared. +.IP "Guarantee #4" 6 +.br +Although possible to make this guarantee, +\fIsystem\fR() +would have to set the SIGCHLD handler to SIG_DFL so that the SIGCHLD +signal generated by its +\fIfork\fR() +would be discarded (the SIGCHLD default action is to be ignored), then +restore it to its previous setting. This would have the undesirable +side-effect of discarding all SIGCHLD signals pending to the process. +.SH "FUTURE DIRECTIONS" +None. +.SH "SEE ALSO" +.IR "Section 2.13" ", " "Status Information", +.IR "\fIexec\fR\^", +.IR "\fIexit\fR\^(\|)", +.IR "\fIfork\fR\^(\|)", +.IR "\fIsystem\fR\^(\|)", +.IR "\fIwaitid\fR\^(\|)" +.P +The Base Definitions volume of POSIX.1\(hy2017, +.IR "Section 4.12" ", " "Memory Synchronization", +.IR "\fB<signal.h>\fP", +.IR "\fB<sys_wait.h>\fP" +.\" +.SH COPYRIGHT +Portions of this text are reprinted and reproduced in electronic form +from IEEE Std 1003.1-2017, Standard for Information Technology +-- Portable Operating System Interface (POSIX), The Open Group Base +Specifications Issue 7, 2018 Edition, +Copyright (C) 2018 by the Institute of +Electrical and Electronics Engineers, Inc and The Open Group. +In the event of any discrepancy between this version and the original IEEE and +The Open Group Standard, the original IEEE and The Open Group Standard +is the referee document. The original Standard can be obtained online at +http://www.opengroup.org/unix/online.html . +.PP +Any typographical or formatting errors that appear +in this page are most likely +to have been introduced during the conversion of the source files to +man page format. To report such errors, see +https://www.kernel.org/doc/man-pages/reporting_bugs.html . |