_exit.html

posix标准英文,html格式

shall complete as if the <i>_Exit</i>() or <i>_exit</i>() operation had not yet occurred, but any associated signal notifications
shall be suppressed. The <i>_Exit</i>() or <i>_exit</i>() operation may block awaiting such I/O completion. Whether any I/O is
canceled, and which I/O may be canceled upon <i>_Exit</i>() or <i>_exit</i>(), is implementation-defined. <img src=
"../images/opt-end.gif" alt="[Option End]" border="0"></p>
</li>

<li>
<p>Threads terminated by a call to <i>_Exit</i>() or <i>_exit</i>() shall not invoke their cancellation cleanup handlers or
per-thread data destructors.</p>
</li>

<li>
<p><sup>[<a href="javascript:open_code('TRC')">TRC</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
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 <a href="../functions/posix_trace_shutdown.html"><i>posix_trace_shutdown</i>()</a> function, and any process'
mapping of trace event names to trace event type identifiers built for these trace streams may be deallocated. <img src=
"../images/opt-end.gif" alt="[Option End]" border="0"></p>
</li>
</ul>
</blockquote>

<h4><a name="tag_03_131_04"></a>RETURN VALUE</h4>

<blockquote>
<p>These functions do not return.</p>
</blockquote>

<h4><a name="tag_03_131_05"></a>ERRORS</h4>

<blockquote>
<p>No errors are defined.</p>
</blockquote>

<hr>
<div class="box"><em>The following sections are informative.</em></div>

<h4><a name="tag_03_131_06"></a>EXAMPLES</h4>

<blockquote>
<p>None.</p>
</blockquote>

<h4><a name="tag_03_131_07"></a>APPLICATION USAGE</h4>

<blockquote>
<p>Normally applications should use <i>exit</i>() rather than <i>_Exit</i>() or <i>_exit</i>().</p>
</blockquote>

<h4><a name="tag_03_131_08"></a>RATIONALE</h4>

<blockquote>
<h5><a name="tag_03_131_08_01"></a>Process Termination</h5>

<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 &quot;actions&quot;, as discussed below. Subsequent proposals distinguished three
types of termination: <i>normal termination</i> (as in the current specification), <i>simple abnormal termination</i>, and
<i>abnormal termination with actions</i>. 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 IEEE&nbsp;Std&nbsp;1003.1-2001.</p>

<p>The implementation-defined actions usually include, in most historical implementations, the creation of a file named <b>core</b>
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>

<p>There is a potential security problem in creating a <b>core</b> 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
<b>core</b> file or should make it unreadable by the user.</p>

<p>Despite the silence of this volume of IEEE&nbsp;Std&nbsp;1003.1-2001 on this feature, applications are advised not to create
files named <b>core</b> because of potential conflicts in many implementations. Some implementations use a name other than
<b>core</b> for the file; for example, by appending the process ID to the filename.</p>

<h5><a name="tag_03_131_08_02"></a>Terminating a Process</h5>

<p>It is important that the consequences of process termination as described occur regardless of whether the process called
<i>_exit</i>() (perhaps indirectly through <i>exit</i>()) or instead was terminated due to a signal or for some other reason. Note
that in the specific case of <i>exit</i>() this means that the <i>status</i> argument to <i>exit</i>() is treated in the same way
as the <i>status</i> argument to <i>_exit</i>().</p>

<p>A language other than C may have other termination primitives than the C-language <i>exit</i>() 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
<i>_exit</i>() as described. Implementations in languages other than C are outside the scope of this version of this volume of
IEEE&nbsp;Std&nbsp;1003.1-2001, however.</p>

<p>As required by the ISO&nbsp;C standard, using <b>return</b> from <i>main</i>() has the same behavior (other than with respect to
language scope issues) as calling <i>exit</i>() with the returned value. Reaching the end of the <i>main</i>() function has the
same behavior as calling <i>exit</i>(0).</p>

<p>A value of zero (or EXIT_SUCCESS, which is required to be zero) for the argument <i>status</i> conventionally indicates
successful termination. This corresponds to the specification for <i>exit</i>() in the ISO&nbsp;C standard. The convention is
followed by utilities such as <a href="../utilities/make.html"><i>make</i></a> and various shells, which interpret a zero status
from a child process as success. For this reason, applications should not call <i>exit</i>(0) or <i>_exit</i>(0) when they
terminate unsuccessfully; for example, in signal-catching functions.</p>

<p>Historically, the implementation-defined process that inherits children whose parents have terminated without waiting on them is
called <i>init</i> and has a process ID of 1.</p>

<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 <i>vhangup</i>() 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 <i>_exit</i>() behave this way in such systems should not cause problems with existing
applications.</p>

<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>

<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 IEEE&nbsp;Std&nbsp;1003.1-2001, the signals
are sent to the entire process group at the same time. Also, in this volume of IEEE&nbsp;Std&nbsp;1003.1-2001, 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
<i>_exit</i>() must consider processes other than child processes.</p>

<p>It is possible for a process group to be orphaned by a call to <a href="../functions/setpgid.html"><i>setpgid</i>()</a> or <a
href="../functions/setsid.html"><i>setsid</i>()</a>, as well as by process termination. This volume of
IEEE&nbsp;Std&nbsp;1003.1-2001 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 <a href=
"../basedefs/signal.h.html"><i>&lt;signal.h&gt;</i></a>.</p>

<p>The ISO/IEC&nbsp;9899:1999 standard adds the <i>_Exit</i>() function that results in immediate program termination without
triggering signals or <a href="../functions/atexit.html"><i>atexit</i>()</a>-registered functions. In
IEEE&nbsp;Std&nbsp;1003.1-2001, this is equivalent to the <i>_exit</i>() function.</p>
</blockquote>

<h4><a name="tag_03_131_09"></a>FUTURE DIRECTIONS</h4>

<blockquote>
<p>None.</p>
</blockquote>

<h4><a name="tag_03_131_10"></a>SEE ALSO</h4>

<blockquote>
<p><a href="atexit.html"><i>atexit</i>()</a>, <a href="close.html"><i>close</i>()</a>, <a href="fclose.html"><i>fclose</i>()</a>
, <a href="longjmp.html"><i>longjmp</i>()</a>, <a href="posix_trace_shutdown.html"><i>posix_trace_shutdown</i>()</a>, <a href=
"posix_trace_trid_eventid_open.html"><i>posix_trace_trid_eventid_open</i>()</a>, <a href="semop.html"><i>semop</i>()</a>, <a
href="shmget.html"><i>shmget</i>()</a>, <a href="sigaction.html"><i>sigaction</i>()</a>, <a href="wait.html"><i>wait</i>()</a>,
<a href="waitid.html"><i>waitid</i>()</a>, <a href="waitpid.html"><i>waitpid</i>()</a>, the Base Definitions volume of
IEEE&nbsp;Std&nbsp;1003.1-2001, <a href="../basedefs/stdlib.h.html"><i>&lt;stdlib.h&gt;</i></a>, <a href=
"../basedefs/unistd.h.html"><i>&lt;unistd.h&gt;</i></a></p>
</blockquote>

<h4><a name="tag_03_131_11"></a>CHANGE HISTORY</h4>

<blockquote>
<p>First released in Issue 1. Derived from Issue 1 of the SVID.</p>
</blockquote>

<h4><a name="tag_03_131_12"></a>Issue 5</h4>

<blockquote>
<p>The DESCRIPTION is updated for alignment with the POSIX Realtime Extension and the POSIX Threads Extension.</p>

<p>Interactions with the SA_NOCLDWAIT flag and SIGCHLD signal are further clarified.</p>

<p>The values of <i>status</i> from <i>exit</i>() are better described.</p>
</blockquote>

<h4><a name="tag_03_131_13"></a>Issue 6</h4>

<blockquote>
<p>Extensions beyond the ISO&nbsp;C standard are marked.</p>

<p>The DESCRIPTION is updated for alignment with IEEE&nbsp;Std&nbsp;1003.1j-2000 by adding semantics for typed memory.</p>

<p>The following changes are made for alignment with the ISO/IEC&nbsp;9899:1999 standard:</p>

<ul>
<li>
<p>The <i>_Exit</i>() function is included.</p>
</li>

<li>
<p>The DESCRIPTION is updated.</p>
</li>
</ul>

<p>The description of tracing semantics is added for alignment with IEEE&nbsp;Std&nbsp;1003.1q-2000.</p>

<p>References to the <i>wait3</i>() function are removed.</p>

<p>IEEE&nbsp;Std 1003.1-2001/Cor&nbsp;1-2002, item XSH/TC1/D6/16 is applied, correcting grammar in the DESCRIPTION.</p>
</blockquote>

<div class="box"><em>End of informative text.</em></div>

<hr size="2" noshade>
<center><font size="2"><!--footer start-->
UNIX &reg; is a registered Trademark of The Open Group.<br>
POSIX &reg; is a registered Trademark of The IEEE.<br>
[ <a href="../mindex.html">Main Index</a> | <a href="../basedefs/contents.html">XBD</a> | <a href=
"../utilities/contents.html">XCU</a> | <a href="../functions/contents.html">XSH</a> | <a href="../xrat/contents.html">XRAT</a>
]</font></center>

<!--footer end-->
<hr size="2" noshade>
</body>
</html>