On Apache/1.3.41 (Unix) PHP/5.2.5 mod_perl/1.30 mod_gzip/1.3.26.1a
Under GNU General Public License
2009-01-10 10:04 @38.103.63.58 CrawledBy CCBot/1.0 (+http://www.commoncrawl.org/bot.html)
POSIX_SPAWN(P) POSIX_SPAWN(P)
NAME
posix_spawn, posix_spawnp - spawn a process (ADVANCED REALTIME)
SYNOPSIS
#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]);
DESCRIPTION
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 con-
structed 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:
extern char **environ;
shall be initialized as a pointer to an array of character pointers to the environ-
ment 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 environ-
ment lists is {ARG_MAX}. The implementation shall specify in the system documenta-
tion (see the Base Definitions volume of IEEE Std 1003.1-2001, Chapter 2, Confor-
mance) 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 char-
acter, 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 vol-
ume 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 pro-
cess 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 correspond-
ing 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 pro-
cess 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 pro-
cess 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_SETSCHED-
PARAM flag), the new process image shall initially have the scheduling policy spec-
ified 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 par-
ent’s real group ID. In either case, if the set-group-ID mode bit of the new pro-
cess 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 unspeci-
fied 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 ref-
erenced 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 manipula-
tions 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 fam-
ily 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.
RETURN VALUE
Upon successful completion, posix_spawn() and posix_spawnp() shall return the pro-
cess 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. Other-
wise, 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.
ERRORS
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 sta-
tus 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 refer-
enced 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 ref-
erenced by attrp, and if posix_spawn() or posix_spawnp() fails for any of the rea-
sons 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.
EXAMPLES
None.
APPLICATION USAGE
These functions are part of the Spawn option and need not be provided on all imple-
mentations.
RATIONALE
The posix_spawn() function and its close relation posix_spawnp() have been intro-
duced 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 use-
ful.
* 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 effi-
ciently 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 parame-
ters. 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 descrip-
tor 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 deci-
sions 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 modi-
fication 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, keep-
ing 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 opera-
tion. 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 operat-
ing systems that are not UNIX systems.
Requirements
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 use-
ful, 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.
Two-Syntax
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, there-
fore, 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().
Compatibility with POSIX.5 (Ada)
The Start_Process and Start_Process_Search procedures from the POSIX_Process_Primi-
tives 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 lim-
ited the capabilities of posix_spawn() and posix_spawnp() to a subset of the capa-
bilities of Start_Process and Start_Process_Search; certain non-default capabili-
ties 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 justi-
fication 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().
Process Group
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.
Threads
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 capa-
bilities, 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 operat-
ing system support required to support multiple processes. The total cost of sup-
port for multiple processes may be quite high in some circumstances. Existing
practice shows that support for multiple processes is uncommon and threads are com-
mon among "tiny kernels". There should, therefore, probably continue to be AEPs
for operating systems with only one process.
Asynchronous Error Notification
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 suc-
cessfully 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 WIFSPAWN-
FAIL 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 informa-
tion 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 pro-
cess 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 pro-
vide 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 fail-
ure 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 pro-
cess 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.
FUTURE DIRECTIONS
None.
SEE ALSO
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_getsigde-
fault() , posix_spawnattr_getflags() , posix_spawnattr_getpgroup() , posix_spaw-
nattr_getschedparam() , posix_spawnattr_getschedpolicy() , posix_spawnattr_getsig-
mask() , posix_spawnattr_setsigdefault() , posix_spawnattr_setflags() , posix_spaw-
nattr_setpgroup() , posix_spawnattr_setschedparam() , posix_spawnattr_setschedpol-
icy() , posix_spawnattr_setsigmask() , sched_setparam() , sched_setscheduler() ,
setpgid() , setuid() , stat() , times() , wait() , the Base Definitions volume of
IEEE Std 1003.1-2001, <spawn.h>
COPYRIGHT
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 .
POSIX 2003 POSIX_SPAWN(P)
Generated by $Id: phpMan.php,v 4.55 2007/09/05 04:42:51 chedong Exp $ Author: Che Dong
On Apache/1.3.41 (Unix) PHP/5.2.5 mod_perl/1.30 mod_gzip/1.3.26.1a
Under GNU General Public License
2009-01-10 10:04 @38.103.63.58 CrawledBy CCBot/1.0 (+http://www.commoncrawl.org/bot.html)