fork(2) System Calls fork(2)NAME
fork, fork1, forkall - create a new process
SYNOPSIS
#include <sys/types.h>
#include <unistd.h>
pid_t fork(void);
pid_t fork1(void);
pid_t forkall(void);
DESCRIPTION
The fork(), fork1(), and forkall() functions create a new process. The
address space of the new process (child process) is an exact copy of
the address space of the calling process (parent process). The child
process inherits the following attributes from the parent process:
· real user ID, real group ID, effective user ID, effective group ID
· environment
· open file descriptors
· close-on-exec flags (see exec(2))
· signal handling settings (that is, SIG_DFL, SIG_IGN, SIG_HOLD,
function address)
· supplementary group IDs
· set-user-ID mode bit
· set-group-ID mode bit
· profiling on/off status
· nice value (see nice(2))
· scheduler class (see priocntl(2))
· all attached shared memory segments (see shmop(2))
· process group ID -- memory mappings (see mmap(2))
· session ID (see exit(2))
· current working directory
· root directory
· file mode creation mask (see umask(2))
· resource limits (see getrlimit(2))
· controlling terminal
· saved user ID and group ID
· task ID and project ID
· processor bindings (see processor_bind(2))
· processor set bindings (see pset_bind(2))
· process privilege sets (see getppriv(2))
· process flags (see getpflags(2))
· active contract templates (see contract(4))
Scheduling priority and any per-process scheduling parameters that are
specific to a given scheduling class might or might not be inherited
according to the policy of that particular class (see priocntl(2)). The
child process might or might not be in the same process contract as the
parent (see process(4)). The child process differs from the parent
process in the following ways:
· The child process has a unique process ID which does not match any
active process group ID.
· The child process has a different parent process ID (that is, the
process ID of the parent process).
· The child process has its own copy of the parent's file descrip‐
tors and directory streams. Each of the child's file descriptors
shares a common file pointer with the corresponding file descrip‐
tor of the parent.
· Each shared memory segment remains attached and the value of
shm_nattach is incremented by 1.
· All semadj values are cleared (see semop(2)).
· Process locks, text locks, data locks, and other memory locks are
not inherited by the child (see plock(3C) and memcntl(2)).
· The child process's tms structure is cleared: tms_utime, stime,
cutime, and cstime are set to 0 (see times(2)).
· The child processes resource utilizations are set to 0; see getr‐
limit(2). The it_value and it_interval values for the ITIMER_REAL
timer are reset to 0; see getitimer(2).
· The set of signals pending for the child process is initialized to
the empty set.
· Timers created by timer_create(3RT) are not inherited by the child
process.
· No asynchronous input or asynchronous output operations are inher‐
ited by the child.
· Any preferred hardware address tranlsation sizes (see memcntl(2))
are inherited by the child.
· The child process holds no contracts (see contract(4)).
Record locks set by the parent process are not inherited by the child
process (see fcntl(2)).
Although any open door descriptors in the parent are shared by the
child, only the parent will receive a door invocation from clients even
if the door descriptor is open in the child. If a descriptor is closed
in the parent, attempts to operate on the door descriptor will fail
even if it is still open in the child.
Threads
A call to forkall() replicates in the child process all of the threads
(see thr_create(3C) and pthread_create(3C)) in the parent process. A
call to fork1() replicates only the calling thread in the child
process.
In Solaris 10, a call to fork() is identical to a call to fork1(); only
the calling thread is replicated in the child process. This is the
POSIX-specified behavior for fork().
In previous releases of Solaris, the behavior of fork() depended on
whether or not the application was linked with the POSIX threads
library. When linked with -lthread (Solaris Threads) but not linked
with -lpthread (POSIX Threads), fork() was the same as forkall(). When
linked with -lpthread, whether or not also linked with -lthread, fork()
was the same as fork1().
In Solaris 10, neither -lthread nor -lpthread is required for multi‐
threaded applications. The standard C library provides all threading
support for both sets of application programming interfaces. Applica‐
tions that require replicate-all fork semantics must call forkall().
fork() Safety
If a multithreaded application calls fork() or fork1(), and the child
does more than simply call one of the exec(2) functions, there is a
possibility of deadlock occurring in the child. The application should
use pthread_atfork(3C) to ensure safety with respect to this deadlock.
Should there be any outstanding mutexes throughout the process, the
application should call pthread_atfork() to wait for and acquire those
mutexes prior to calling fork() or fork1(). See "MT-Level of
Libraries" on the attributes(5) manual page.
RETURN VALUES
Upon successful completion, fork(), fork1(), and forkall() return 0 to
the child process and return the process ID of the child process to the
parent process. Otherwise, (pid_t)−1 is returned to the parent process,
no child process is created, and errno is set to indicate the error.
ERRORS
The fork(), fork1(), and forkall()function will fail if:
EAGAIN A resource control or limit on the total number of
processes, tasks or LWPs under execution by a single
user, task, project, or zone has been exceeded, or the
total amount of system memory available is temporarily
insufficient to duplicate this process.
ENOMEM There is not enough swap space.
EPERM The {PRIV_PROC_FORK} privilege is not asserted in the
effective set of the calling process.
ATTRIBUTES
See attributes(5) for descriptions of the following attributes:
┌─────────────────────────────┬─────────────────────────────┐
│ ATTRIBUTE TYPE │ ATTRIBUTE VALUE │
├─────────────────────────────┼─────────────────────────────┤
│Interface Stability │fork() is Standard. fork1() │
│ │and forkall() are Stable. │
├─────────────────────────────┼─────────────────────────────┤
│MT-Level │Async-Signal-Safe. │
└─────────────────────────────┴─────────────────────────────┘
SEE ALSOalarm(2), exec(2), exit(2), fcntl(2), getitimer(2), getrlimit(2), mem‐
cntl(2), mmap(2), nice(2), priocntl(2), semop(2), shmop(2), times(2),
umask(2), door_create(3DOOR), exit(3C), plock(3C), pthread_atfork(3C),
pthread_create(3C), signal(3C), system(3C), thr_create(3C) timer_cre‐
ate(3RT), wait(3C), contract(4), process(4)attributes(5), privi‐
leges(5), standards(5)NOTES
An applications should call _exit() rather than exit(3C) if it cannot
execve(), since exit() will flush and close standard I/O channels and
thereby corrupt the parent process's standard I/O data structures.
Using exit(3C) will flush buffered data twice. See exit(2).
The thread in the child that calls fork() or fork1() must not depend on
any resources held by threads that no longer exist in the child. In
particular, locks held by these threads will not be released.
In a multithreaded process, forkall() in one thread can cause blocking
system calls to be interrupted and return with an EINTR error.
SunOS 5.10 19 Jul 2004 fork(2)
