fork.html

posix标准英文,html格式

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

<blockquote>
<p>Upon successful completion, <i>fork</i>() shall return 0 to the child process and shall return the process ID of the child
process to the parent process. Both processes shall continue to execute from the <i>fork</i>() function. Otherwise, -1 shall be
returned to the parent process, no child process shall be created, and <i>errno</i> shall be set to indicate the error.</p>
</blockquote>

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

<blockquote>
<p>The <i>fork</i>() function shall fail if:</p>

<dl compact>
<dt>[EAGAIN]</dt>

<dd>The system lacked the necessary resources to create another process, or the system-imposed limit on the total number of
processes under execution system-wide or by a single user {CHILD_MAX} would be exceeded.</dd>
</dl>

<br>
<p>The <i>fork</i>() function may fail if:</p>

<dl compact>
<dt>[ENOMEM]</dt>

<dd>Insufficient storage space is available.</dd>
</dl>
</blockquote>

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

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

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

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

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

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

<blockquote>
<p>Many historical implementations have timing windows where a signal sent to a process group (for example, an interactive SIGINT)
just prior to or during execution of <i>fork</i>() is delivered to the parent following the <i>fork</i>() but not to the child
because the <i>fork</i>() code clears the child's set of pending signals. This volume of IEEE&nbsp;Std&nbsp;1003.1-2001 does not
require, or even permit, this behavior. However, it is pragmatic to expect that problems of this nature may continue to exist in
implementations that appear to conform to this volume of IEEE&nbsp;Std&nbsp;1003.1-2001 and pass available verification suites.
This behavior is only a consequence of the implementation failing to make the interval between signal generation and delivery
totally invisible. From the application's perspective, a <i>fork</i>() call should appear atomic. A signal that is generated prior
to the <i>fork</i>() should be delivered prior to the <i>fork</i>(). A signal sent to the process group after the <i>fork</i>()
should be delivered to both parent and child. The implementation may actually initialize internal data structures corresponding to
the child's set of pending signals to include signals sent to the process group during the <i>fork</i>(). Since the <i>fork</i>()
call can be considered as atomic from the application's perspective, the set would be initialized as empty and such signals would
have arrived after the <i>fork</i>(); see also <a href="../basedefs/signal.h.html"><i>&lt;signal.h&gt;</i></a>.</p>

<p>One approach that has been suggested to address the problem of signal inheritance across <i>fork</i>() is to add an [EINTR]
error, which would be returned when a signal is detected during the call. While this is preferable to losing signals, it was not
considered an optimal solution. Although it is not recommended for this purpose, such an error would be an allowable extension for
an implementation.</p>

<p>The [ENOMEM] error value is reserved for those implementations that detect and distinguish such a condition. This condition
occurs when an implementation detects that there is not enough memory to create the process. This is intended to be returned when
[EAGAIN] is inappropriate because there can never be enough memory (either primary or secondary storage) to perform the operation.
Since <i>fork</i>() duplicates an existing process, this must be a condition where there is sufficient memory for one such process,
but not for two. Many historical implementations actually return [ENOMEM] due to temporary lack of memory, a case that is not
generally distinct from [EAGAIN] from the perspective of a conforming application.</p>

<p>Part of the reason for including the optional error [ENOMEM] is because the SVID specifies it and it should be reserved for the
error condition specified there. The condition is not applicable on many implementations.</p>

<p>IEEE&nbsp;Std&nbsp;1003.1-1988 neglected to require concurrent execution of the parent and child of <i>fork</i>(). A system that
single-threads processes was clearly not intended and is considered an unacceptable &quot;toy implementation&quot; of this volume of
IEEE&nbsp;Std&nbsp;1003.1-2001. The only objection anticipated to the phrase &quot;executing independently&quot; is testability, but this
assertion should be testable. Such tests require that both the parent and child can block on a detectable action of the other, such
as a write to a pipe or a signal. An interactive exchange of such actions should be possible for the system to conform to the
intent of this volume of IEEE&nbsp;Std&nbsp;1003.1-2001.</p>

<p>The [EAGAIN] error exists to warn applications that such a condition might occur. Whether it occurs or not is not in any
practical sense under the control of the application because the condition is usually a consequence of the user's use of the
system, not of the application's code. Thus, no application can or should rely upon its occurrence under any circumstances, nor
should the exact semantics of what concept of &quot;user&quot; is used be of concern to the application writer. Validation writers should
be cognizant of this limitation.</p>

<p>There are two reasons why POSIX programmers call <i>fork</i>(). One reason is to create a new thread of control within the same
program (which was originally only possible in POSIX by creating a new process); the other is to create a new process running a
different program. In the latter case, the call to <i>fork</i>() is soon followed by a call to one of the <i><a href=
"../functions/exec.html">exec</a></i> functions.</p>

<p>The general problem with making <i>fork</i>() work in a multi-threaded world is what to do with all of the threads. There are
two alternatives. One is to copy all of the threads into the new process. This causes the programmer or implementation to deal with
threads that are suspended on system calls or that might be about to execute system calls that should not be executed in the new
process. The other alternative is to copy only the thread that calls <i>fork</i>(). This creates the difficulty that the state of
process-local resources is usually held in process memory. If a thread that is not calling <i>fork</i>() holds a resource, that
resource is never released in the child process because the thread whose job it is to release the resource does not exist in the
child process.</p>

<p>When a programmer is writing a multi-threaded program, the first described use of <i>fork</i>(), creating new threads in the
same program, is provided by the <a href="../functions/pthread_create.html"><i>pthread_create</i>()</a> function. The <i>fork</i>()
function is thus used only to run new programs, and the effects of calling functions that require certain resources between the
call to <i>fork</i>() and the call to an <i><a href="../functions/exec.html">exec</a></i> function are undefined.</p>

<p>The addition of the <i>forkall</i>() function to the standard was considered and rejected. The <i>forkall</i>() function lets
all the threads in the parent be duplicated in the child. This essentially duplicates the state of the parent in the child. This
allows threads in the child to continue processing and allows locks and the state to be preserved without explicit <a href=
"../functions/pthread_atfork.html"><i>pthread_atfork</i>()</a> code. The calling process has to ensure that the threads processing
state that is shared between the parent and child (that is, file descriptors or MAP_SHARED memory) behaves properly after
<i>forkall</i>(). For example, if a thread is reading a file descriptor in the parent when <i>forkall</i>() is called, then two
threads (one in the parent and one in the child) are reading the file descriptor after the <i>forkall</i>(). If this is not desired
behavior, the parent process has to synchronize with such threads before calling <i>forkall</i>().</p>

<p>While the <i>fork</i>() function is async-signal-safe, there is no way for an implementation to determine whether the fork
handlers established by <a href="../functions/pthread_atfork.html"><i>pthread_atfork</i>()</a> are async-signal-safe. The fork
handlers may attempt to execute portions of the implementation that are not async-signal-safe, such as those that are protected by
mutexes, leading to a deadlock condition. It is therefore undefined for the fork handlers to execute functions that are not
async-signal-safe when <i>fork</i>() is called from a signal handler.</p>

<p>When <i>forkall</i>() is called, threads, other than the calling thread, that are in functions that can return with an [EINTR]
error may have those functions return [EINTR] if the implementation cannot ensure that the function behaves correctly in the parent
and child. In particular, <a href="../functions/pthread_cond_wait.html"><i>pthread_cond_wait</i>()</a> and <a href=
"../functions/pthread_cond_timedwait.html"><i>pthread_cond_timedwait</i>()</a> need to return in order to ensure that the condition
has not changed. These functions can be awakened by a spurious condition wakeup rather than returning [EINTR].</p>
</blockquote>

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

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

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

<blockquote>
<p><a href="alarm.html"><i>alarm</i>()</a>, <a href="exec.html"><i><a href="../functions/exec.html">exec</a></i>()</a>, <a href=
"fcntl.html"><i>fcntl</i>()</a>, <a href="posix_trace_attr_getinherited.html"><i>posix_trace_attr_getinherited</i>()</a>, <a
href="posix_trace_trid_eventid_open.html"><i>posix_trace_trid_eventid_open</i>()</a>, <a href=
"pthread_atfork.html"><i>pthread_atfork</i>()</a>, <a href="semop.html"><i>semop</i>()</a>, <a href=
"signal.html"><i>signal</i>()</a>, <a href="times.html"><i>times</i>()</a>, the Base Definitions volume of
IEEE&nbsp;Std&nbsp;1003.1-2001, <a href="../basedefs/sys/types.h.html"><i>&lt;sys/types.h&gt;</i></a>, <a href=
"../basedefs/unistd.h.html"><i>&lt;unistd.h&gt;</i></a></p>
</blockquote>

<h4><a name="tag_03_177_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_177_12"></a>Issue 5</h4>

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

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

<blockquote>
<p>The following new requirements on POSIX implementations derive from alignment with the Single UNIX Specification:</p>

<ul>
<li>
<p>The requirement to include <a href="../basedefs/sys/types.h.html"><i>&lt;sys/types.h&gt;</i></a> has been removed. Although <a
href="../basedefs/sys/types.h.html"><i>&lt;sys/types.h&gt;</i></a> was required for conforming implementations of previous POSIX
specifications, it was not required for UNIX applications.</p>
</li>
</ul>

<p>The following changes were made to align with the IEEE&nbsp;P1003.1a draft standard:</p>

<ul>
<li>
<p>The effect of <i>fork</i>() on a pending alarm call in the child process is clarified.</p>
</li>
</ul>

<p>The description of CPU-time clock semantics is added for alignment with IEEE&nbsp;Std&nbsp;1003.1d-1999.</p>

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

<p>IEEE&nbsp;Std 1003.1-2001/Cor&nbsp;1-2002, item XSH/TC1/D6/17 is applied, adding text to the DESCRIPTION and RATIONALE relating
to fork handlers registered by the <a href="../functions/pthread_atfork.html"><i>pthread_atfork</i>()</a> function and async-signal
safety.</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>