Originální popis anglicky:
fork - create a new process
Návod, kniha: POSIX Programmer's Manual
#include <unistd.h>
pid_t fork(void);
The
fork() 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:
- *
- The child process shall have a unique process ID.
- *
- The child process ID also shall not match any active
process group ID.
- *
- The child process shall have a different parent process ID,
which shall be the process ID of the calling process.
- *
- 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.
- *
- 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.
- *
- The child process shall have its own copy of the parent's
message catalog descriptors.
- *
- The child process' values of tms_utime,
tms_stime, tms_cutime, and tms_cstime shall be set to
0.
- *
- The time left until an alarm clock signal shall be reset to
zero, and the alarm, if any, shall be canceled; see alarm() .
- *
- All semadj values shall be cleared.
- *
- File locks set by the parent process shall not be inherited
by the child process.
- *
- The set of signals pending for the child process shall be
initialized to the empty set.
- *
- Interval timers shall be reset in the child process.
- *
- Any semaphores that are open in the parent process shall
also be open in the child process.
- *
- The child process shall not inherit any address space
memory locks established by the parent process via calls to
mlockall() or mlock().
- *
- 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 fork()
shall be visible to the child. Any modifications to the data in
MAP_PRIVATE mappings made by the parent after fork() 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.
- *
- 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 fork() function. For other scheduling policies,
the policy and priority settings on fork() are
implementation-defined.
- *
- Per-process timers created by the parent shall not be
inherited by the child process.
- *
- 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.
- *
- No asynchronous input or asynchronous output operations
shall be inherited by the child process.
- *
- A process shall be created with a single thread. If a
multi-threaded process calls fork(), 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 exec functions is called.
Fork handlers may be established by means of the
pthread_atfork() function in order to maintain application
invariants across fork() calls.
When the application calls
fork() from a signal handler and any of the
fork handlers registered by
pthread_atfork() calls a function that is
not asynch-signal-safe, the behavior is undefined.
- *
- If the Trace option and the Trace Inherit option are both
supported:
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
posix_trace_attr_setinherited() function.
- *
- If the Trace option is supported, but the Trace Inherit
option is not supported:
The child process shall not be traced into any of the trace streams of its
parent process.
- *
- 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.
- *
- The initial value of the CPU-time clock of the child
process shall be set to zero.
- *
- The initial value of the CPU-time clock of the single
thread of the child process shall be set to zero.
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.
After
fork(), both the parent and the child processes shall be capable of
executing independently before either one terminates.
Upon successful completion,
fork() 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
fork() function.
Otherwise, -1 shall be returned to the parent process, no child process shall
be created, and
errno shall be set to indicate the error.
The
fork() function shall fail if:
- EAGAIN
- 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.
The
fork() function may fail if:
- ENOMEM
- Insufficient storage space is available.
The following sections are informative.
None.
None.
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
fork() is delivered to the parent following the
fork() but not to the child because the
fork() 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
fork() call should appear atomic. A signal
that is generated prior to the
fork() should be delivered prior to the
fork(). A signal sent to the process group after the
fork()
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
fork(). Since the
fork() 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
fork(); see also
<signal.h>.
One approach that has been suggested to address the problem of signal
inheritance across
fork() 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.
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
fork() 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.
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.
IEEE Std 1003.1-1988 neglected to require concurrent execution of
the parent and child of
fork(). 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.
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.
There are two reasons why POSIX programmers call
fork(). 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
fork() is soon followed by a call to one of the
exec functions.
The general problem with making
fork() 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
fork(). This creates the difficulty that the state of process-local
resources is usually held in process memory. If a thread that is not calling
fork() 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.
When a programmer is writing a multi-threaded program, the first described use
of
fork(), creating new threads in the same program, is provided by the
pthread_create() function. The
fork() function is thus used only
to run new programs, and the effects of calling functions that require certain
resources between the call to
fork() and the call to an
exec
function are undefined.
The addition of the
forkall() function to the standard was considered and
rejected. The
forkall() 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
pthread_atfork() 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
forkall(). For example, if a thread is reading a file descriptor in the
parent when
forkall() is called, then two threads (one in the parent
and one in the child) are reading the file descriptor after the
forkall(). If this is not desired behavior, the parent process has to
synchronize with such threads before calling
forkall().
While the
fork() function is async-signal-safe, there is no way for an
implementation to determine whether the fork handlers established by
pthread_atfork() 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
fork() is called from a signal handler.
When
forkall() 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,
pthread_cond_wait() and
pthread_cond_timedwait() 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].
None.
alarm() ,
exec() ,
fcntl() ,
posix_trace_attr_getinherited() ,
posix_trace_trid_eventid_open() ,
pthread_atfork() ,
semop() ,
signal() ,
times() , the Base Definitions
volume of IEEE Std 1003.1-2001,
<sys/types.h>,
<unistd.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
.
