Originální popis anglicky:
posix_spawn, posix_spawnp - spawn a process (
ADVANCED REALTIME)
Návod, kniha: POSIX Programmer's Manual
#include <spawn.h>
int posix_spawn(pid_t *restrict
pid, const char
*restrict path,
const
posix_spawn_file_actions_t *
file_actions,
const posix_spawnattr_t
*restrict
attrp,
char *const
argv[restrict], char *const
envp[restrict]);
int posix_spawnp(pid_t *restrict
pid, const char
*restrict file,
const
posix_spawn_file_actions_t *
file_actions,
const posix_spawnattr_t
*restrict
attrp,
char *const
argv[restrict], char * const
envp [restrict]);
The
posix_spawn() and
posix_spawnp() functions shall create a new
process (child process) from the specified process image. The new process
image shall be constructed from a regular executable file called the new
process image file.
When a C program is executed as the result of this call, it shall be entered as
a C-language function call as follows:
int main(int argc, char *argv[]);
where
argc is the argument count and
argv is an array of character
pointers to the arguments themselves. In addition, the following variable:
shall be initialized as a pointer to an array of character pointers to the
environment strings.
The argument
argv is an array of character pointers to null-terminated
strings. The last member of this array shall be a null pointer and is not
counted in
argc. These strings constitute the argument list available
to the new process image. The value in
argv[0] should point to a
filename that is associated with the process image being started by the
posix_spawn() or
posix_spawnp() function.
The argument
envp is an array of character pointers to null-terminated
strings. These strings constitute the environment for the new process image.
The environment array is terminated by a null pointer.
The number of bytes available for the child process' combined argument and
environment lists is {ARG_MAX}. The implementation shall specify in the system
documentation (see the Base Definitions volume of
IEEE Std 1003.1-2001, Chapter 2, Conformance) whether any list
overhead, such as length words, null terminators, pointers, or alignment
bytes, is included in this total.
The
path argument to
posix_spawn() is a pathname that identifies
the new process image file to execute.
The
file parameter to
posix_spawnp() shall be used to construct a
pathname that identifies the new process image file. If the
file
parameter contains a slash character, the
file parameter shall be used
as the pathname for the new process image file. Otherwise, the path prefix for
this file shall be obtained by a search of the directories passed as the
environment variable
PATH (see the Base Definitions volume of
IEEE Std 1003.1-2001, Chapter 8, Environment Variables). If this
environment variable is not defined, the results of the search are
implementation-defined.
If
file_actions is a null pointer, then file descriptors open in the
calling process shall remain open in the child process, except for those whose
close-on-
exec flag FD_CLOEXEC is set (see
fcntl() ). For those
file descriptors that remain open, all attributes of the corresponding open
file descriptions, including file locks (see
fcntl() ), shall remain
unchanged.
If
file_actions is not NULL, then the file descriptors open in the child
process shall be those open in the calling process as modified by the spawn
file actions object pointed to by
file_actions and the FD_CLOEXEC flag
of each remaining open file descriptor after the spawn file actions have been
processed. The effective order of processing the spawn file actions shall be:
- 1.
- The set of open file descriptors for the child process
shall initially be the same set as is open for the calling process. All
attributes of the corresponding open file descriptions, including file
locks (see fcntl() ), shall remain unchanged.
- 2.
- The signal mask, signal default actions, and the effective
user and group IDs for the child process shall be changed as specified in
the attributes object referenced by attrp.
- 3.
- The file actions specified by the spawn file actions object
shall be performed in the order in which they were added to the spawn file
actions object.
- 4.
- Any file descriptor that has its FD_CLOEXEC flag set (see
fcntl() ) shall be closed.
The
posix_spawnattr_t spawn attributes object type is defined in
<spawn.h>. It shall contain at least the attributes defined
below.
If the POSIX_SPAWN_SETPGROUP flag is set in the
spawn-flags attribute of
the object referenced by
attrp, and the
spawn-pgroup attribute
of the same object is non-zero, then the child's process group shall be as
specified in the
spawn-pgroup attribute of the object referenced by
attrp.
As a special case, if the POSIX_SPAWN_SETPGROUP flag is set in the
spawn-flags attribute of the object referenced by
attrp, and the
spawn-pgroup attribute of the same object is set to zero, then the
child shall be in a new process group with a process group ID equal to its
process ID.
If the POSIX_SPAWN_SETPGROUP flag is not set in the
spawn-flags attribute
of the object referenced by
attrp, the new child process shall inherit
the parent's process group.
If the POSIX_SPAWN_SETSCHEDPARAM flag is set in the
spawn-flags attribute
of the object referenced by
attrp, but POSIX_SPAWN_SETSCHEDULER is not
set, the new process image shall initially have the scheduling policy of the
calling process with the scheduling parameters specified in the
spawn-schedparam attribute of the object referenced by
attrp.
If the POSIX_SPAWN_SETSCHEDULER flag is set in the
spawn-flags attribute
of the object referenced by
attrp (regardless of the setting of the
POSIX_SPAWN_SETSCHEDPARAM flag), the new process image shall initially have
the scheduling policy specified in the
spawn-schedpolicy attribute of
the object referenced by
attrp and the scheduling parameters specified
in the
spawn-schedparam attribute of the same object.
The POSIX_SPAWN_RESETIDS flag in the
spawn-flags attribute of the object
referenced by
attrp governs the effective user ID of the child process.
If this flag is not set, the child process shall inherit the parent process'
effective user ID. If this flag is set, the child process' effective user ID
shall be reset to the parent's real user ID. In either case, if the
set-user-ID mode bit of the new process image file is set, the effective user
ID of the child process shall become that file's owner ID before the new
process image begins execution.
The POSIX_SPAWN_RESETIDS flag in the
spawn-flags attribute of the object
referenced by
attrp also governs the effective group ID of the child
process. If this flag is not set, the child process shall inherit the parent
process' effective group ID. If this flag is set, the child process' effective
group ID shall be reset to the parent's real group ID. In either case, if the
set-group-ID mode bit of the new process image file is set, the effective
group ID of the child process shall become that file's group ID before the new
process image begins execution.
If the POSIX_SPAWN_SETSIGMASK flag is set in the
spawn-flags attribute of
the object referenced by
attrp, the child process shall initially have
the signal mask specified in the
spawn-sigmask attribute of the object
referenced by
attrp.
If the POSIX_SPAWN_SETSIGDEF flag is set in the
spawn-flags attribute of
the object referenced by
attrp, the signals specified in the
spawn-sigdefault attribute of the same object shall be set to their
default actions in the child process. Signals set to the default action in the
parent process shall be set to the default action in the child process.
Signals set to be caught by the calling process shall be set to the default
action in the child process.
Except for SIGCHLD, signals set to be ignored by the calling process image shall
be set to be ignored by the child process, unless otherwise specified by the
POSIX_SPAWN_SETSIGDEF flag being set in the
spawn-flags attribute of
the object referenced by
attrp and the signals being indicated in the
spawn-sigdefault attribute of the object referenced by
attrp.
If the SIGCHLD signal is set to be ignored by the calling process, it is
unspecified whether the SIGCHLD signal is set to be ignored or to the default
action in the child process, unless otherwise specified by the
POSIX_SPAWN_SETSIGDEF flag being set in the
spawn_flags attribute of
the object referenced by
attrp and the SIGCHLD signal being indicated
in the
spawn_sigdefault attribute of the object referenced by
attrp.
If the value of the
attrp pointer is NULL, then the default values are
used.
All process attributes, other than those influenced by the attributes set in the
object referenced by
attrp as specified above or by the file descriptor
manipulations specified in
file_actions, shall appear in the new
process image as though
fork() had been called to create a child
process and then a member of the
exec family of functions had been
called by the child process to execute the new process image.
It is implementation-defined whether the fork handlers are run when
posix_spawn() or
posix_spawnp() is called.
Upon successful completion,
posix_spawn() and
posix_spawnp() shall
return the process ID of the child process to the parent process, in the
variable pointed to by a non-NULL
pid argument, and shall return zero
as the function return value. Otherwise, no child process shall be created,
the value stored into the variable pointed to by a non-NULL
pid is
unspecified, and an error number shall be returned as the function return
value to indicate the error. If the
pid argument is a null pointer, the
process ID of the child is not returned to the caller.
The
posix_spawn() and
posix_spawnp() functions may fail if:
- EINVAL
- The value specified by file_actions or attrp
is invalid.
If this error occurs after the calling process successfully returns from the
posix_spawn() or
posix_spawnp() function, the child process may
exit with exit status 127.
If
posix_spawn() or
posix_spawnp() fail for any of the reasons
that would cause
fork() or one of the
exec family of functions
to fail, an error value shall be returned as described by
fork() and
exec, respectively (or, if the error occurs after the calling process
successfully returns, the child process shall exit with exit status 127).
If POSIX_SPAWN_SETPGROUP is set in the
spawn-flags attribute of the
object referenced by
attrp, and
posix_spawn() or
posix_spawnp() fails while changing the child's process group, an error
value shall be returned as described by
setpgid() (or, if the error
occurs after the calling process successfully returns, the child process shall
exit with exit status 127).
If POSIX_SPAWN_SETSCHEDPARAM is set and POSIX_SPAWN_SETSCHEDULER is not set in
the
spawn-flags attribute of the object referenced by
attrp,
then if
posix_spawn() or
posix_spawnp() fails for any of the
reasons that would cause
sched_setparam() to fail, an error value shall
be returned as described by
sched_setparam() (or, if the error occurs
after the calling process successfully returns, the child process shall exit
with exit status 127).
If POSIX_SPAWN_SETSCHEDULER is set in the
spawn-flags attribute of the
object referenced by
attrp, and if
posix_spawn() or
posix_spawnp() fails for any of the reasons that would cause
sched_setscheduler() to fail, an error value shall be returned as
described by
sched_setscheduler() (or, if the error occurs after the
calling process successfully returns, the child process shall exit with exit
status 127).
If the
file_actions argument is not NULL, and specifies any
close,
dup2, or
open actions to be performed, and if
posix_spawn() or
posix_spawnp() fails for any of the reasons
that would cause
close(),
dup2(), or
open() to fail, an
error value shall be returned as described by
close(),
dup2(),
and
open(), respectively (or, if the error occurs after the calling
process successfully returns, the child process shall exit with exit status
127). An open file action may, by itself, result in any of the errors
described by
close() or
dup2(), in addition to those described
by
open().
The following sections are informative.
None.
These functions are part of the Spawn option and need not be provided on all
implementations.
The
posix_spawn() function and its close relation
posix_spawnp()
have been introduced to overcome the following perceived difficulties with
fork(): the
fork() function is difficult or impossible to
implement without swapping or dynamic address translation.
- *
- Swapping is generally too slow for a realtime
environment.
- *
- Dynamic address translation is not available everywhere
that POSIX might be useful.
- *
- Processes are too useful to simply option out of POSIX
whenever it must run without address translation or other MMU
services.
Thus, POSIX needs process creation and file execution primitives that can be
efficiently implemented without address translation or other MMU services.
The
posix_spawn() function is implementable as a library routine, but
both
posix_spawn() and
posix_spawnp() are designed as kernel
operations. Also, although they may be an efficient replacement for many
fork()/
exec pairs, their goal is to provide useful process
creation primitives for systems that have difficulty with
fork(), not
to provide drop-in replacements for
fork()/
exec.
This view of the role of
posix_spawn() and
posix_spawnp()
influenced the design of their API. It does not attempt to provide the full
functionality of
fork()/
exec in which arbitrary user-specified
operations of any sort are permitted between the creation of the child process
and the execution of the new process image; any attempt to reach that level
would need to provide a programming language as parameters. Instead,
posix_spawn() and
posix_spawnp() are process creation primitives
like the
Start_Process and
Start_Process_Search Ada language
bindings package
POSIX_Process_Primitives and also like those in many
operating systems that are not UNIX systems, but with some POSIX-specific
additions.
To achieve its coverage goals,
posix_spawn() and
posix_spawnp()
have control of six types of inheritance: file descriptors, process group ID,
user and group ID, signal mask, scheduling, and whether each signal ignored in
the parent will remain ignored in the child, or be reset to its default action
in the child.
Control of file descriptors is required to allow an independently written child
process image to access data streams opened by and even generated or read by
the parent process without being specifically coded to know which parent files
and file descriptors are to be used. Control of the process group ID is
required to control how the child process' job control relates to that of the
parent.
Control of the signal mask and signal defaulting is sufficient to support the
implementation of
system(). Although support for
system() is not
explicitly one of the goals for
posix_spawn() and
posix_spawnp(), it is covered under the "at least 50%"
coverage goal.
The intention is that the normal file descriptor inheritance across
fork(), the subsequent effect of the specified spawn file actions, and
the normal file descriptor inheritance across one of the
exec family of
functions should fully specify open file inheritance. The implementation need
make no decisions regarding the set of open file descriptors when the child
process image begins execution, those decisions having already been made by
the caller and expressed as the set of open file descriptors and their
FD_CLOEXEC flags at the time of the call and the spawn file actions object
specified in the call. We have been assured that in cases where the POSIX
Start_Process Ada primitives have been implemented in a library, this
method of controlling file descriptor inheritance may be implemented very
easily.
We can identify several problems with
posix_spawn() and
posix_spawnp(), but there does not appear to be a solution that
introduces fewer problems. Environment modification for child process
attributes not specifiable via the
attrp or
file_actions
arguments must be done in the parent process, and since the parent generally
wants to save its context, it is more costly than similar functionality with
fork()/
exec. It is also complicated to modify the environment
of a multi-threaded process temporarily, since all threads must agree when it
is safe for the environment to be changed. However, this cost is only borne by
those invocations of
posix_spawn() and
posix_spawnp() that use
the additional functionality. Since extensive modifications are not the usual
case, and are particularly unlikely in time-critical code, keeping much of the
environment control out of
posix_spawn() and
posix_spawnp() is
appropriate design.
The
posix_spawn() and
posix_spawnp() functions do not have all the
power of
fork()/
exec. This is to be expected. The
fork()
function is a wonderfully powerful operation. We do not expect to duplicate
its functionality in a simple, fast function with no special hardware
requirements. It is worth noting that
posix_spawn() and
posix_spawnp() are very similar to the process creation operations on
many operating systems that are not UNIX systems.
The requirements for
posix_spawn() and
posix_spawnp() are:
- *
- They must be implementable without an MMU or unusual
hardware.
- *
- They must be compatible with existing POSIX standards.
Additional goals are:
- *
- They should be efficiently implementable.
- *
- They should be able to replace at least 50% of typical
executions of fork().
- *
- A system with posix_spawn() and
posix_spawnp() and without fork() should be useful, at least
for realtime applications.
- *
- A system with fork() and the exec family
should be able to implement posix_spawn() and posix_spawnp()
as library routines.
POSIX
exec 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
posix_spawn*() functions
is otherwise substantially unlike POSIX, we feel that simplicity outweighs
compatibility. There are, therefore, only two names for the
posix_spawn*() functions.
The parameter list does not differ between
posix_spawn() and
posix_spawnp();
posix_spawnp() interprets the second parameter
more elaborately than
posix_spawn().
The
Start_Process and
Start_Process_Search procedures from the
POSIX_Process_Primitives package from the Ada language binding to
POSIX.1 encapsulate
fork() and
exec functionality in a manner
similar to that of
posix_spawn() and
posix_spawnp(). Originally,
in keeping with our simplicity goal, the standard developers had limited the
capabilities of
posix_spawn() and
posix_spawnp() to a subset of
the capabilities of
Start_Process and
Start_Process_Search;
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
posix_spawn() and
posix_spawnp() should be sufficiently powerful to implement
Start_Process and
Start_Process_Search. 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
posix_spawn() and
posix_spawnp() that are not
provided by
Start_Process and
Start_Process_Search 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.
For the Ada language binding for
Start_Process to be implemented with
posix_spawn(), that binding would need to explicitly pass an empty
signal mask and the parent's environment to
posix_spawn() whenever the
caller of
Start_Process allowed these arguments to default, since
posix_spawn() does not provide such defaults. The ability of
Start_Process 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
posix_spawn().
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
spawn-pgroup attribute of the object referenced by
attrp, the
setpgid() mechanism will place the child process in a new process
group.
Without the
posix_spawn() and
posix_spawnp() 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
posix_spawn() and
posix_spawnp() functions
are considerably "heavier" 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.
The
posix_spawn() and
posix_spawnp() 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 "tiny kernels".
There should, therefore, probably continue to be AEPs for operating systems
with only one process.
A library implementation of
posix_spawn() or
posix_spawnp() may
not be able to detect all possible errors before it forks the child process.
IEEE Std 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
wait() and
waitpid().
The
stat_val 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
posix_spawn() or
posix_spawnp() function
has successfully returned.
The standard developers had proposed using two additional macros to interpret
stat_val. The first, WIFSPAWNFAIL, would have detected a status that
indicated that the child exited because of an error detected during the
posix_spawn() or
posix_spawnp() 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
posix_spawn() or
posix_spawnp()
dependent on kernel modifications to
waitpid() to be able to embed
special information in
stat_val to indicate a spawn failure.
The 8 bits of child process exit status that are guaranteed by
IEEE Std 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
stat_val, 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
system() and
popen() 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
posix_spawn() or
posix_spawnp() is permitted (and encouraged) to return any possible
error as the function value, thus providing more detailed failure information
to the parent process.
Thus, no special macros are available to isolate asynchronous
posix_spawn() or
posix_spawnp() errors. Instead, errors detected
by the
posix_spawn() or
posix_spawnp() 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
stat_val stored by the
wait() or
waitpid() 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.
None.
alarm() ,
chmod() ,
close() ,
dup() ,
exec()
,
exit() ,
fcntl() ,
fork() ,
kill() ,
open() ,
posix_spawn_file_actions_addclose() ,
posix_spawn_file_actions_adddup2() ,
posix_spawn_file_actions_addopen() ,
posix_spawn_file_actions_destroy() , ,
posix_spawnattr_destroy()
,
posix_spawnattr_init() ,
posix_spawnattr_getsigdefault() ,
posix_spawnattr_getflags() ,
posix_spawnattr_getpgroup() ,
posix_spawnattr_getschedparam() ,
posix_spawnattr_getschedpolicy() ,
posix_spawnattr_getsigmask()
,
posix_spawnattr_setsigdefault() ,
posix_spawnattr_setflags() ,
posix_spawnattr_setpgroup() ,
posix_spawnattr_setschedparam() ,
posix_spawnattr_setschedpolicy() ,
posix_spawnattr_setsigmask()
,
sched_setparam() ,
sched_setscheduler() ,
setpgid() ,
setuid() ,
stat() ,
times() ,
wait() , the Base
Definitions volume of IEEE Std 1003.1-2001,
<spawn.h>
Portions of this text are reprinted and reproduced in electronic form from IEEE
Std 1003.1, 2003 Edition, Standard for Information Technology -- Portable
Operating System Interface (POSIX), The Open Group Base Specifications Issue
6, Copyright (C) 2001-2003 by the Institute of Electrical and Electronics
Engineers, Inc and The Open Group. 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.opengroup.org/unix/online.html
.
