posix_spawnp.html

posix标准英文,html格式

<ul>
<li>
<p>They should be efficiently implementable.</p>
</li>

<li>
<p>They should be able to replace at least 50% of typical executions of <a href="../functions/fork.html"><i>fork</i>()</a>.</p>
</li>

<li>
<p>A system with <i>posix_spawn</i>() and <i>posix_spawnp</i>() and without <a href="../functions/fork.html"><i>fork</i>()</a>
should be useful, at least for realtime applications.</p>
</li>

<li>
<p>A system with <a href="../functions/fork.html"><i>fork</i>()</a> and the <i><a href="../functions/exec.html">exec</a></i> family
should be able to implement <i>posix_spawn</i>() and <i>posix_spawnp</i>() as library routines.</p>
</li>
</ul>

<h5><a name="tag_03_427_08_02"></a>Two-Syntax</h5>

<p>POSIX <i><a href="../functions/exec.html">exec</a></i> has several calling sequences with approximately the same functionality.
These appear to be required for compatibility with existing practice. Since the existing practice for the <a href=
"../functions/posix_spawn.html"><i>posix_spawn*</i>()</a> functions is otherwise substantially unlike POSIX, we feel that
simplicity outweighs compatibility. There are, therefore, only two names for the <a href=
"../functions/posix_spawn.html"><i>posix_spawn*</i>()</a> functions.</p>

<p>The parameter list does not differ between <i>posix_spawn</i>() and <i>posix_spawnp</i>(); <i>posix_spawnp</i>() interprets the
second parameter more elaborately than <i>posix_spawn</i>().</p>

<h5><a name="tag_03_427_08_03"></a>Compatibility with POSIX.5 (Ada)</h5>

<p>The <i>Start_Process</i> and <i>Start_Process_Search</i> procedures from the <i>POSIX_Process_Primitives</i> package from the
Ada language binding to POSIX.1 encapsulate <a href="../functions/fork.html"><i>fork</i>()</a> and <i><a href=
"../functions/exec.html">exec</a></i> functionality in a manner similar to that of <i>posix_spawn</i>() and <i>posix_spawnp</i>().
Originally, in keeping with our simplicity goal, the standard developers had limited the capabilities of <i>posix_spawn</i>() and
<i>posix_spawnp</i>() to a subset of the capabilities of <i>Start_Process</i> and <i>Start_Process_Search</i>; certain non-default
capabilities were not supported. However, based on suggestions by the ballot group to improve file descriptor mapping or drop it,
and on the advice of an Ada Language Bindings working group member, the standard developers decided that <i>posix_spawn</i>() and
<i>posix_spawnp</i>() should be sufficiently powerful to implement <i>Start_Process</i> and <i>Start_Process_Search</i>. The
rationale is that if the Ada language binding to such a primitive had already been approved as an IEEE standard, there can be
little justification for not approving the functionally-equivalent parts of a C binding. The only three capabilities provided by
<i>posix_spawn</i>() and <i>posix_spawnp</i>() that are not provided by <i>Start_Process</i> and <i>Start_Process_Search</i> are
optionally specifying the child's process group ID, the set of signals to be reset to default signal handling in the child process,
and the child's scheduling policy and parameters.</p>

<p>For the Ada language binding for <i>Start_Process</i> to be implemented with <i>posix_spawn</i>(), that binding would need to
explicitly pass an empty signal mask and the parent's environment to <i>posix_spawn</i>() whenever the caller of
<i>Start_Process</i> allowed these arguments to default, since <i>posix_spawn</i>() does not provide such defaults. The ability of
<i>Start_Process</i> to mask user-specified signals during its execution is functionally unique to the Ada language binding and
must be dealt with in the binding separately from the call to <i>posix_spawn</i>().</p>

<h5><a name="tag_03_427_08_04"></a>Process Group</h5>

<p>The process group inheritance field can be used to join the child process with an existing process group. By assigning a value
of zero to the <i>spawn-pgroup</i> attribute of the object referenced by <i>attrp</i>, the <a href=
"../functions/setpgid.html"><i>setpgid</i>()</a> mechanism will place the child process in a new process group.</p>

<h5><a name="tag_03_427_08_05"></a>Threads</h5>

<p>Without the <i>posix_spawn</i>() and <i>posix_spawnp</i>() functions, systems without address translation can still use threads
to give an abstraction of concurrency. In many cases, thread creation suffices, but it is not always a good substitute. The
<i>posix_spawn</i>() and <i>posix_spawnp</i>() functions are considerably &quot;heavier&quot; than thread creation. Processes have several
important attributes that threads do not. Even without address translation, a process may have base-and-bound memory protection.
Each process has a process environment including security attributes and file capabilities, and powerful scheduling attributes.
Processes abstract the behavior of non-uniform-memory-architecture multi-processors better than threads, and they are more
convenient to use for activities that are not closely linked.</p>

<p>The <i>posix_spawn</i>() and <i>posix_spawnp</i>() functions may not bring support for multiple processes to every
configuration. Process creation is not the only piece of operating system support required to support multiple processes. The total
cost of support for multiple processes may be quite high in some circumstances. Existing practice shows that support for multiple
processes is uncommon and threads are common among &quot;tiny kernels&quot;. There should, therefore, probably continue to be AEPs for
operating systems with only one process.</p>

<h5><a name="tag_03_427_08_06"></a>Asynchronous Error Notification</h5>

<p>A library implementation of <i>posix_spawn</i>() or <i>posix_spawnp</i>() may not be able to detect all possible errors before
it forks the child process. IEEE&nbsp;Std&nbsp;1003.1-2001 provides for an error indication returned from a child process which
could not successfully complete the spawn operation via a special exit status which may be detected using the status value returned
by <a href="../functions/wait.html"><i>wait</i>()</a> and <a href="../functions/waitpid.html"><i>waitpid</i>()</a>.</p>

<p>The <i>stat_val</i> interface and the macros used to interpret it are not well suited to the purpose of returning API errors,
but they are the only path available to a library implementation. Thus, an implementation may cause the child process to exit with
exit status 127 for any error detected during the spawn process after the <i>posix_spawn</i>() or <i>posix_spawnp</i>() function
has successfully returned.</p>

<p>The standard developers had proposed using two additional macros to interpret <i>stat_val</i>. The first, WIFSPAWNFAIL, would
have detected a status that indicated that the child exited because of an error detected during the <i>posix_spawn</i>() or
<i>posix_spawnp</i>() operations rather than during actual execution of the child process image; the second, WSPAWNERRNO, would
have extracted the error value if WIFSPAWNFAIL indicated a failure. Unfortunately, the ballot group strongly opposed this because
it would make a library implementation of <i>posix_spawn</i>() or <i>posix_spawnp</i>() dependent on kernel modifications to <a
href="../functions/waitpid.html"><i>waitpid</i>()</a> to be able to embed special information in <i>stat_val</i> to indicate a
spawn failure.</p>

<p>The 8 bits of child process exit status that are guaranteed by IEEE&nbsp;Std&nbsp;1003.1-2001 to be accessible to the waiting
parent process are insufficient to disambiguate a spawn error from any other kind of error that may be returned by an arbitrary
process image. No other bits of the exit status are required to be visible in <i>stat_val</i>, so these macros could not be
strictly implemented at the library level. Reserving an exit status of 127 for such spawn errors is consistent with the use of this
value by <a href="../functions/system.html"><i>system</i>()</a> and <a href="../functions/popen.html"><i>popen</i>()</a> to signal
failures in these operations that occur after the function has returned but before a shell is able to execute. The exit status of
127 does not uniquely identify this class of error, nor does it provide any detailed information on the nature of the failure. Note
that a kernel implementation of <i>posix_spawn</i>() or <i>posix_spawnp</i>() is permitted (and encouraged) to return any possible
error as the function value, thus providing more detailed failure information to the parent process.</p>

<p>Thus, no special macros are available to isolate asynchronous <i>posix_spawn</i>() or <i>posix_spawnp</i>() errors. Instead,
errors detected by the <i>posix_spawn</i>() or <i>posix_spawnp</i>() operations in the context of the child process before the new
process image executes are reported by setting the child's exit status to 127. The calling process may use the WIFEXITED and
WEXITSTATUS macros on the <i>stat_val</i> stored by the <a href="../functions/wait.html"><i>wait</i>()</a> or <a href=
"../functions/waitpid.html"><i>waitpid</i>()</a> functions to detect spawn failures to the extent that other status values with
which the child process image may exit (before the parent can conclusively determine that the child process image has begun
execution) are distinct from exit status 127.</p>
</blockquote>

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

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

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

<blockquote>
<p><a href="alarm.html"><i>alarm</i>()</a>, <a href="chmod.html"><i>chmod</i>()</a>, <a href="close.html"><i>close</i>()</a>, <a
href="dup.html"><i>dup</i>()</a>, <a href="exec.html"><i><a href="../functions/exec.html">exec</a></i>()</a>, <a href=
"exit.html"><i>exit</i>()</a>, <a href="fcntl.html"><i>fcntl</i>()</a>, <a href="fork.html"><i>fork</i>()</a>, <a href=
"kill.html"><i>kill</i>()</a>, <a href="open.html"><i>open</i>()</a>, <a href=
"posix_spawn_file_actions_addclose.html"><i>posix_spawn_file_actions_addclose</i>()</a>, <a href=
"posix_spawn_file_actions_adddup2.html"><i>posix_spawn_file_actions_adddup2</i>()</a>, <a href=
"posix_spawn_file_actions_addopen.html"><i>posix_spawn_file_actions_addopen</i>()</a>, <a href=
"posix_spawn_file_actions_destroy.html"><i>posix_spawn_file_actions_destroy</i>()</a>, <a href=
"posix_spawnattr_destroy.html"><i>posix_spawnattr_destroy</i>()</a>, <a href=
"posix_spawnattr_init.html"><i>posix_spawnattr_init</i>()</a>, <a href=
"posix_spawnattr_getsigdefault.html"><i>posix_spawnattr_getsigdefault</i>()</a>, <a href=
"posix_spawnattr_getflags.html"><i>posix_spawnattr_getflags</i>()</a>, <a href=
"posix_spawnattr_getpgroup.html"><i>posix_spawnattr_getpgroup</i>()</a>, <a href=
"posix_spawnattr_getschedparam.html"><i>posix_spawnattr_getschedparam</i>()</a>, <a href=
"posix_spawnattr_getschedpolicy.html"><i>posix_spawnattr_getschedpolicy</i>()</a>, <a href=
"posix_spawnattr_getsigmask.html"><i>posix_spawnattr_getsigmask</i>()</a>, <a href=
"posix_spawnattr_setsigdefault.html"><i>posix_spawnattr_setsigdefault</i>()</a>, <a href=
"posix_spawnattr_setflags.html"><i>posix_spawnattr_setflags</i>()</a>, <a href=
"posix_spawnattr_setpgroup.html"><i>posix_spawnattr_setpgroup</i>()</a>, <a href=
"posix_spawnattr_setschedparam.html"><i>posix_spawnattr_setschedparam</i>()</a>, <a href=
"posix_spawnattr_setschedpolicy.html"><i>posix_spawnattr_setschedpolicy</i>()</a>, <a href=
"posix_spawnattr_setsigmask.html"><i>posix_spawnattr_setsigmask</i>()</a>, <a href=
"sched_setparam.html"><i>sched_setparam</i>()</a>, <a href="sched_setscheduler.html"><i>sched_setscheduler</i>()</a>, <a href=
"setpgid.html"><i>setpgid</i>()</a>, <a href="setuid.html"><i>setuid</i>()</a>, <a href="stat.html"><i>stat</i>()</a>, <a href=
"times.html"><i>times</i>()</a>, <a href="wait.html"><i>wait</i>()</a>, the Base Definitions volume of
IEEE&nbsp;Std&nbsp;1003.1-2001, <a href="../basedefs/spawn.h.html"><i>&lt;spawn.h&gt;</i></a></p>
</blockquote>

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

<blockquote>
<p>First released in Issue 6. Derived from IEEE&nbsp;Std&nbsp;1003.1d-1999.</p>

<p>IEEE PASC Interpretation 1003.1 #103 is applied, noting that the signal default actions are changed as well as the signal mask
in step 2.</p>

<p>IEEE PASC Interpretation 1003.1 #132 is applied.</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>