395 lines
21 KiB
HTML
395 lines
21 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<html>
|
|
<head>
|
|
<meta name="generator" content="HTML Tidy, see www.w3.org">
|
|
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
|
|
<link type="text/css" rel="stylesheet" href="style.css"><!-- Generated by The Open Group's rhtm tool v1.2.1 -->
|
|
<!-- Copyright (c) 2001 The Open Group, All Rights Reserved -->
|
|
<title>fork</title>
|
|
</head>
|
|
<body bgcolor="white">
|
|
<script type="text/javascript" language="JavaScript" src="../jscript/codes.js">
|
|
</script>
|
|
|
|
<basefont size="3"> <a name="fork"></a> <a name="tag_03_177"></a><!-- fork -->
|
|
<!--header start-->
|
|
<center><font size="2">The Open Group Base Specifications Issue 6<br>
|
|
IEEE Std 1003.1-2001<br>
|
|
Copyright © 2001 The IEEE and The Open Group, All Rights reserved.</font></center>
|
|
|
|
<!--header end-->
|
|
<hr size="2" noshade>
|
|
<h4><a name="tag_03_177_01"></a>NAME</h4>
|
|
|
|
<blockquote>fork - create a new process</blockquote>
|
|
|
|
<h4><a name="tag_03_177_02"></a>SYNOPSIS</h4>
|
|
|
|
<blockquote class="synopsis">
|
|
<p><code><tt>#include <<a href="../basedefs/unistd.h.html">unistd.h</a>><br>
|
|
<br>
|
|
pid_t fork(void);<br>
|
|
</tt></code></p>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_177_03"></a>DESCRIPTION</h4>
|
|
|
|
<blockquote>
|
|
<p>The <i>fork</i>() function shall create a new process. The new process (child process) shall be an exact copy of the calling
|
|
process (parent process) except as detailed below:</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p>The child process shall have a unique process ID.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>The child process ID also shall not match any active process group ID.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>The child process shall have a different parent process ID, which shall be the process ID of the calling process.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>The child process shall have its own copy of the parent's file descriptors. Each of the child's file descriptors shall refer to
|
|
the same open file description with the corresponding file descriptor of the parent.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>The child process shall have its own copy of the parent's open directory streams. Each open directory stream in the child
|
|
process may share directory stream positioning with the corresponding directory stream of the parent.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><sup>[<a href="javascript:open_code('XSI')">XSI</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
|
|
The child process shall have its own copy of the parent's message catalog descriptors. <img src="../images/opt-end.gif" alt=
|
|
"[Option End]" border="0"></p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>The child process' values of <i>tms_utime</i>, <i>tms_stime</i>, <i>tms_cutime</i>, and <i>tms_cstime</i> shall be set to 0.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>The time left until an alarm clock signal shall be reset to zero, and the alarm, if any, shall be canceled; see <a href=
|
|
"alarm.html"><i>alarm</i>()</a> .</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><sup>[<a href="javascript:open_code('XSI')">XSI</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
|
|
All <i>semadj</i> values shall be cleared. <img src="../images/opt-end.gif" alt="[Option End]" border="0"></p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>File locks set by the parent process shall not be inherited by the child process.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>The set of signals pending for the child process shall be initialized to the empty set.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><sup>[<a href="javascript:open_code('XSI')">XSI</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
|
|
Interval timers shall be reset in the child process. <img src="../images/opt-end.gif" alt="[Option End]" border="0"></p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><sup>[<a href="javascript:open_code('SEM')">SEM</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
|
|
Any semaphores that are open in the parent process shall also be open in the child process. <img src="../images/opt-end.gif" alt=
|
|
"[Option End]" border="0"></p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><sup>[<a href="javascript:open_code('ML')">ML</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0"> The
|
|
child process shall not inherit any address space memory locks established by the parent process via calls to <a href=
|
|
"../functions/mlockall.html"><i>mlockall</i>()</a> or <a href="../functions/mlock.html"><i>mlock</i>()</a>. <img src=
|
|
"../images/opt-end.gif" alt="[Option End]" border="0"></p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><sup>[<a href="javascript:open_code('MF')">MF|SHM</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
|
|
Memory mappings created in the parent shall be retained in the child process. MAP_PRIVATE mappings inherited from the parent shall
|
|
also be MAP_PRIVATE mappings in the child, and any modifications to the data in these mappings made by the parent prior to calling
|
|
<i>fork</i>() shall be visible to the child. Any modifications to the data in MAP_PRIVATE mappings made by the parent after
|
|
<i>fork</i>() returns shall be visible only to the parent. Modifications to the data in MAP_PRIVATE mappings made by the child
|
|
shall be visible only to the child. <img src="../images/opt-end.gif" alt="[Option End]" border="0"></p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><sup>[<a href="javascript:open_code('PS')">PS</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0"> For
|
|
the SCHED_FIFO and SCHED_RR scheduling policies, the child process shall inherit the policy and priority settings of the parent
|
|
process during a <i>fork</i>() function. For other scheduling policies, the policy and priority settings on <i>fork</i>() are
|
|
implementation-defined. <img src="../images/opt-end.gif" alt="[Option End]" border="0"></p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><sup>[<a href="javascript:open_code('TMR')">TMR</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
|
|
Per-process timers created by the parent shall not be inherited by the child process. <img src="../images/opt-end.gif" alt=
|
|
"[Option End]" border="0"></p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><sup>[<a href="javascript:open_code('MSG')">MSG</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
|
|
The child process shall have its own copy of the message queue descriptors of the parent. Each of the message descriptors of the
|
|
child shall refer to the same open message queue description as the corresponding message descriptor of the parent. <img src=
|
|
"../images/opt-end.gif" alt="[Option End]" border="0"></p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><sup>[<a href="javascript:open_code('AIO')">AIO</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
|
|
No asynchronous input or asynchronous output operations shall be inherited by the child process. <img src="../images/opt-end.gif"
|
|
alt="[Option End]" border="0"></p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>A process shall be created with a single thread. If a multi-threaded process calls <i>fork</i>(), the new process shall contain
|
|
a replica of the calling thread and its entire address space, possibly including the states of mutexes and other resources.
|
|
Consequently, to avoid errors, the child process may only execute async-signal-safe operations until such time as one of the <i><a
|
|
href="../functions/exec.html">exec</a></i> functions is called. <sup>[<a href="javascript:open_code('THR')">THR</a>]</sup> <img
|
|
src="../images/opt-start.gif" alt="[Option Start]" border="0"> Fork handlers may be established by means of the <a href=
|
|
"../functions/pthread_atfork.html"><i>pthread_atfork</i>()</a> function in order to maintain application invariants across
|
|
<i>fork</i>() calls. <img src="../images/opt-end.gif" alt="[Option End]" border="0"></p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><sup>[<a href="javascript:open_code('TRC TRI')">TRC TRI</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]"
|
|
border="0"> If the Trace option and the Trace Inherit option are both supported:</p>
|
|
|
|
<p>If the calling process was being traced in a trace stream that had its inheritance policy set to POSIX_TRACE_INHERITED, the
|
|
child process shall be traced into that trace stream, and the child process shall inherit the parent's mapping of trace event names
|
|
to trace event type identifiers. If the trace stream in which the calling process was being traced had its inheritance policy set
|
|
to POSIX_TRACE_CLOSE_FOR_CHILD, the child process shall not be traced into that trace stream. The inheritance policy is set by a
|
|
call to the <a href="../functions/posix_trace_attr_setinherited.html"><i>posix_trace_attr_setinherited</i>()</a> function. <img
|
|
src="../images/opt-end.gif" alt="[Option End]" border="0"></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 Trace option is supported, but the Trace Inherit option is not supported:</p>
|
|
|
|
<p>The child process shall not be traced into any of the trace streams of its parent process. <img src="../images/opt-end.gif" alt=
|
|
"[Option End]" border="0"></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 Trace option is supported, the child process of a trace controller process shall not control the trace streams controlled by
|
|
its parent process. <img src="../images/opt-end.gif" alt="[Option End]" border="0"></p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><sup>[<a href="javascript:open_code('CPT')">CPT</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
|
|
The initial value of the CPU-time clock of the child process shall be set to zero. <img src="../images/opt-end.gif" alt=
|
|
"[Option End]" border="0"></p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><sup>[<a href="javascript:open_code('TCT')">TCT</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
|
|
The initial value of the CPU-time clock of the single thread of the child process shall be set to zero. <img src=
|
|
"../images/opt-end.gif" alt="[Option End]" border="0"></p>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>All other process characteristics defined by IEEE Std 1003.1-2001 shall be the same in the parent and child processes.
|
|
The inheritance of process characteristics not defined by IEEE Std 1003.1-2001 is unspecified by
|
|
IEEE Std 1003.1-2001.</p>
|
|
|
|
<p>After <i>fork</i>(), both the parent and the child processes shall be capable of executing independently before either one
|
|
terminates.</p>
|
|
</blockquote>
|
|
|
|
<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>
|
|
|
|
<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 Std 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 Std 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><signal.h></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 Std 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 "toy implementation" of this volume of
|
|
IEEE Std 1003.1-2001. The only objection anticipated to the phrase "executing independently" 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 Std 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 "user" 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>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="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 Std 1003.1-2001, <a href="../basedefs/sys/types.h.html"><i><sys/types.h></i></a>, <a href=
|
|
"../basedefs/unistd.h.html"><i><unistd.h></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><sys/types.h></i></a> has been removed. Although <a
|
|
href="../basedefs/sys/types.h.html"><i><sys/types.h></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 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 Std 1003.1d-1999.</p>
|
|
|
|
<p>The description of tracing semantics is added for alignment with IEEE Std 1003.1q-2000.</p>
|
|
</blockquote>
|
|
|
|
<div class="box"><em>End of informative text.</em></div>
|
|
|
|
<hr>
|
|
<hr size="2" noshade>
|
|
<center><font size="2"><!--footer start-->
|
|
UNIX ® is a registered Trademark of The Open Group.<br>
|
|
POSIX ® 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>
|
|
|