diff options
Diffstat (limited to 'man-pages-posix-2013/man3p/_Exit.3p')
| -rw-r--r-- | man-pages-posix-2013/man3p/_Exit.3p | 451 |
1 files changed, 451 insertions, 0 deletions
diff --git a/man-pages-posix-2013/man3p/_Exit.3p b/man-pages-posix-2013/man3p/_Exit.3p new file mode 100644 index 0000000..67bf8b8 --- /dev/null +++ b/man-pages-posix-2013/man3p/_Exit.3p @@ -0,0 +1,451 @@ +'\" et +.TH _EXIT "3P" 2013 "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 +_Exit, +_exit +\(em terminate a process +.SH SYNOPSIS +.LP +.nf +#include <stdlib.h> +.P +void _Exit(int \fIstatus\fP); +.P +#include <unistd.h> +.P +void _exit(int \fIstatus\fP); +.fi +.SH DESCRIPTION +For +\fI_Exit\fR(): +The functionality described on this reference page is aligned with the +ISO\ C standard. Any conflict between the requirements described here and the +ISO\ C standard is unintentional. This volume of POSIX.1\(hy2008 defers to the ISO\ C standard. +.P +The value of +.IR status +may be 0, EXIT_SUCCESS, EXIT_FAILURE, +or any other value, though only the least significant 8 bits (that is, +.IR status +& 0377) shall be available to a waiting parent process. +.P +The +\fI_Exit\fR() +and +\fI_exit\fR() +functions shall be functionally equivalent. +.P +The +\fI_Exit\fR() +and +\fI_exit\fR() +functions shall not call functions registered with +\fIatexit\fR() +nor any registered signal handlers. +Open streams shall not be flushed. +Whether open streams are closed (without flushing) is +implementation-defined. Finally, the calling process shall be +terminated with the consequences described below. +.SS "Consequences of Process Termination" +.P +Process termination caused by any reason shall have the following +consequences: +.TP 10 +.BR Note: +These consequences are all extensions to the ISO\ C standard and are not further +CX shaded. However, functionality relating to the XSI option is shaded. +.P +.IP " *" 4 +All of the file descriptors, directory streams, +conversion descriptors, and message catalog descriptors +open in the calling process shall be closed. +.IP " *" 4 +If the parent process of the calling process is executing a +\fIwait\fR(), +\fIwaitid\fR(), +or +\fIwaitpid\fR(), +and has neither set its SA_NOCLDWAIT flag nor set SIGCHLD to SIG_IGN, +it shall be notified of termination of the calling process and the +low-order eight bits (that is, bits 0377) of +.IR 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 +\fIwait\fR(), +\fIwaitid\fR(), +or +\fIwaitpid\fR(). +.RS 4 +.P +The semantics of the +\fIwaitid\fR() +function shall be equivalent to +\fIwait\fR(). +.RE +.IP " *" 4 +If the parent process of the calling process is not executing a +\fIwait\fR(), +\fIwaitid\fR(), +or +\fIwaitpid\fR(), +and has neither set its SA_NOCLDWAIT flag nor set SIGCHLD to SIG_IGN, +the calling process shall be transformed into a \fIzombie process\fP. +A \fIzombie process\fP is an inactive process and it shall be deleted +at some later time when its parent process executes +\fIwait\fR(), +\fIwaitid\fR(), +or +\fIwaitpid\fR(). +.RS 4 +.P +The semantics of the +\fIwaitid\fR() +function shall be equivalent to +\fIwait\fR(). +.RE +.IP " *" 4 +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. +.IP " *" 4 +Either: +.RS 4 +.P +If the implementation supports the SIGCHLD +signal, a SIGCHLD shall be sent to the parent process. +.P +Or: +.P +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. +.RE +.IP " *" 4 +The parent process ID of all of the existing child processes and +zombie processes of the calling process shall be set to the process ID +of an implementation-defined system process. That is, these processes +shall be inherited by a special system process. +.IP " *" 4 +Each attached shared-memory segment is detached and the value of +.IR shm_nattch +(see +\fIshmget\fR()) +in the data structure associated with its shared memory ID +shall be decremented by 1. +.IP " *" 4 +For each semaphore for which the calling process has set a +.IR semadj +value (see +\fIsemop\fR()), +that value shall be added to the +.IR semval +of the specified semaphore. +.IP " *" 4 +If the process is a controlling process, the SIGHUP +signal shall be sent to each process in the foreground process group of +the controlling terminal belonging to the calling process. +.IP " *" 4 +If the process is a controlling process, the controlling terminal +associated with the session shall be disassociated from the session, +allowing it to be acquired by a new controlling process. +.IP " *" 4 +If the exit of the process causes a process group to become orphaned, +and if any member of the newly-orphaned process group is stopped, then +a SIGHUP signal followed by a SIGCONT signal shall be sent to each +process in the newly-orphaned process group. +.IP " *" 4 +All open named semaphores in the calling process shall be closed as +if by appropriate calls to +\fIsem_close\fR(). +.IP " *" 4 +Any memory locks established by the process via calls to +\fImlockall\fR() +or +\fImlock\fR() +shall be removed. If locked pages in the address space of the calling +process are also mapped into the address spaces of other processes and +are locked by those processes, the locks established by the other +processes shall be unaffected by the call by this process to +\fI_Exit\fR() +or +\fI_exit\fR(). +.IP " *" 4 +Memory mappings that were created in the process shall be unmapped +before the process is destroyed. +.IP " *" 4 +Any blocks of typed memory that were mapped in the calling process +shall be unmapped, as if +\fImunmap\fR() +was implicitly called to unmap them. +.IP " *" 4 +All open message queue descriptors in the calling process shall be +closed as if by appropriate calls to +\fImq_close\fR(). +.IP " *" 4 +Any outstanding cancelable asynchronous I/O operations may be +canceled. Those asynchronous I/O operations that are not canceled +shall complete as if the +\fI_Exit\fR() +or +\fI_exit\fR() +operation had not yet occurred, but any associated signal notifications +shall be suppressed. The +\fI_Exit\fR() +or +\fI_exit\fR() +operation may block awaiting such I/O completion. Whether any +I/O is canceled, and which I/O may be canceled upon +\fI_Exit\fR() +or +\fI_exit\fR(), +is implementation-defined. +.IP " *" 4 +Threads terminated by a call to +\fI_Exit\fR() +or +\fI_exit\fR() +shall not invoke their cancellation cleanup handlers or per-thread data +destructors. +.IP " *" 4 +If the calling process is a trace controller process, any trace streams +that were created by the calling process shall be shut down as +described by the +\fIposix_trace_shutdown\fR() +function, and mapping of trace event names to trace event type identifiers +of any process built for these trace streams may be deallocated. +.SH "RETURN VALUE" +These functions do not return. +.SH ERRORS +No errors are defined. +.LP +.IR "The following sections are informative." +.SH EXAMPLES +None. +.SH "APPLICATION USAGE" +Normally applications should use +\fIexit\fR() +rather than +\fI_Exit\fR() +or +\fI_exit\fR(). +.SH RATIONALE +.SS "Process Termination" +.P +Early proposals drew a distinction between normal and abnormal process +termination. Abnormal termination was caused only by certain signals +and resulted in implementation-defined ``actions'', as discussed below. +Subsequent proposals distinguished three types of termination: +\fInormal termination\fP (as in the current specification), \fIsimple +abnormal termination\fP, and \fIabnormal termination with actions\fP. +Again the distinction between the two types of abnormal termination was +that they were caused by different signals and that +implementation-defined actions would result in the latter case. Given +that these actions were completely implementation-defined, the early +proposals were only saying when the actions could occur and how their +occurrence could be detected, but not what they were. This was of +little or no use to conforming applications, and thus the distinction is +not made in this volume of POSIX.1\(hy2008. +.P +The implementation-defined actions usually include, in most +historical implementations, the creation of a file named +.BR core +in the current working directory of the process. This file contains an +image of the memory of the process, together with descriptive +information about the process, perhaps sufficient to reconstruct the +state of the process at the receipt of the signal. +.P +There is a potential security problem in creating a +.BR core +file if the process was set-user-ID +and the current user is not the owner of the program, if the process +was set-group-ID +and none of the user's groups match the group of the program, or if the +user does not have permission to write in the current directory. In +this situation, an implementation either should not create a +.BR core +file or should make it unreadable by the user. +.P +Despite the silence of this volume of POSIX.1\(hy2008 on this feature, applications are +advised not to create files named +.BR core +because of potential conflicts in many implementations. Some +implementations use a name other than +.BR core +for the file; for example, by appending the process ID to the filename. +.SS "Terminating a Process" +.P +It is important that the consequences of process termination as +described occur regardless of whether the process called +\fI_exit\fR() +(perhaps indirectly through +\fIexit\fR()) +or instead was terminated due to a signal or for some other reason. +Note that in the specific case of +\fIexit\fR() +this means that the +.IR status +argument to +\fIexit\fR() +is treated in the same way as the +.IR status +argument to +\fI_exit\fR(). +.P +A language other than C may have other termination primitives than the +C-language +\fIexit\fR() +function, and programs written in such a language should use its native +termination primitives, but those should have as part of their function +the behavior of +\fI_exit\fR() +as described. Implementations in languages other than C are outside +the scope of this version of this volume of POSIX.1\(hy2008, however. +.P +As required by the ISO\ C standard, using +.BR return +from +\fImain\fR() +has the same behavior (other than with respect to language scope +issues) as calling +\fIexit\fR() +with the returned value. Reaching the end of the +\fImain\fR() +function has the same behavior as calling +.IR exit (0). +.P +A value of zero (or EXIT_SUCCESS, which is required to be zero) +for the argument +.IR status +conventionally indicates successful termination. This corresponds to +the specification for +\fIexit\fR() +in the ISO\ C standard. The convention is followed by utilities such as +.IR make +and various shells, which interpret a zero status +from a child process as success. For this reason, applications should +not call \fIexit\fP(0) or \fI_exit\fP(0) when they terminate +unsuccessfully; for example, in signal-catching functions. +.P +Historically, the implementation-defined process that inherits +children whose parents have terminated without waiting on them is +called +.IR init +and has a process ID of 1. +.P +The sending of a SIGHUP +to the foreground process group when a controlling process terminates +corresponds to somewhat different historical implementations. In System +V, the kernel sends a +SIGHUP on termination of (essentially) a controlling process. In 4.2 BSD, +the kernel does not send SIGHUP in a case like this, but the termination +of a controlling process is usually noticed by a system daemon, which +arranges to send a SIGHUP to the foreground process group with the +\fIvhangup\fR() +function. However, in 4.2 BSD, due to the behavior of the shells that +support job control, +the controlling process is usually a shell with no other processes in +its process group. Thus, a change to make +\fI_exit\fR() +behave this way in such systems should not cause problems with existing +applications. +.P +The termination of a process may cause a process group to become +orphaned in either of two ways. +The connection of a process group to its parent(s) outside of the group +depends on both the parents and their children. Thus, a process group +may be orphaned by the termination of the last connecting parent +process outside of the group or by the termination of the last direct +descendant of the parent process(es). In either case, if the +termination of a process causes a process group to become orphaned, +processes within the group are disconnected from their job control +shell, which no longer has any information on the existence of the +process group. Stopped processes within the group would languish +forever. In order to avoid this problem, newly orphaned process groups +that contain stopped processes are sent a SIGHUP signal and a SIGCONT +signal to indicate that they have been disconnected from their +session. +The SIGHUP signal causes the process group members to terminate unless +they are catching or ignoring SIGHUP. Under most circumstances, all of +the members of the process group are stopped if any of them are +stopped. +.P +The action of sending a SIGHUP and a SIGCONT signal to members of a +newly orphaned process group is similar to the action of 4.2 BSD, which +sends SIGHUP and SIGCONT to each stopped child of an exiting process. +If such children exit in response to the SIGHUP, any additional +descendants receive similar treatment at that time. In this volume of POSIX.1\(hy2008, the +signals are sent to the entire process group at the same time. Also, +in this volume of POSIX.1\(hy2008, but not in 4.2 BSD, stopped processes may be orphaned, but +may be members of a process group that is not orphaned; therefore, the +action taken at +\fI_exit\fR() +must consider processes other than child processes. +.P +It is possible for a process group to be orphaned by a call to +\fIsetpgid\fR() +or +\fIsetsid\fR(), +as well as by process termination. This volume of POSIX.1\(hy2008 does not require sending +SIGHUP and SIGCONT in those cases, because, unlike process termination, +those cases are not caused accidentally by applications that are +unaware of job control. An implementation can choose to send SIGHUP +and SIGCONT in those cases as an extension; such an extension must be +documented as required in +.IR <signal.h> . +.P +The ISO/IEC\ 9899:\|1999 standard adds the +\fI_Exit\fR() +function that results in immediate program termination without +triggering signals or +\fIatexit\fR()-registered +functions. In POSIX.1\(hy2008, this is equivalent to the +\fI_exit\fR() +function. +.SH "FUTURE DIRECTIONS" +None. +.SH "SEE ALSO" +.IR "\fIatexit\fR\^(\|)", +.IR "\fIexit\fR\^(\|)", +.IR "\fImlock\fR\^(\|)", +.IR "\fImlockall\fR\^(\|)", +.IR "\fImq_close\fR\^(\|)", +.IR "\fImunmap\fR\^(\|)", +.IR "\fIposix_trace_create\fR\^(\|)", +.IR "\fIsem_close\fR\^(\|)", +.IR "\fIsemop\fR\^(\|)", +.IR "\fIsetpgid\fR\^(\|)", +.IR "\fIsetsid\fR\^(\|)", +.IR "\fIshmget\fR\^(\|)", +.IR "\fIwait\fR\^(\|)", +.IR "\fIwaitid\fR\^(\|)" +.P +The Base Definitions volume of POSIX.1\(hy2008, +.IR "\fB<stdlib.h>\fP", +.IR "\fB<unistd.h>\fP" +.SH COPYRIGHT +Portions of this text are reprinted and reproduced in electronic form +from IEEE Std 1003.1, 2013 Edition, Standard for Information Technology +-- Portable Operating System Interface (POSIX), The Open Group Base +Specifications Issue 7, Copyright (C) 2013 by the Institute of +Electrical and Electronics Engineers, Inc and The Open Group. +(This is POSIX.1-2008 with the 2013 Technical Corrigendum 1 applied.) 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.unix.org/online.html . + +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 . |