fork(2) fork(2)
NAME
fork, forkall, fork1 - 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
fork (also known as forkall) causes creation of a new process.
The new process (child process) is an exact copy of the
calling process (parent process). This means the child
process inherits the following attributes from the parent
process:
real user ID, real group ID, effective user ID,
effective group ID
environment
close-on-exec flag [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]
process group ID
session ID [see exit]
current working directory
root directory
file mode creation mask [see umask(2)]
resource limits [see getrlimit]
controlling terminal
working and maximum privilege sets
Scheduling priority and any per-process scheduling parameters
that are specific to a given scheduling class may or may not
be inherited according to the policy of that particular class
[see priocntl(2)]. The new process created by forkall
duplicates the calling process, including the set of threads
(and underlying LWPs) that exist as of the time of the call.
Copyright 1994 Novell, Inc. Page 1
fork(2) fork(2)
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
descriptors and directory streams. Each of the child's
file descriptors shares a common file pointer with the
corresponding file descriptor of the parent.
All semadj values are cleared [see semop].
Process locks, text locks and data locks are not
inherited by the child [see plock].
The child process's tms structure is cleared: tms_utime,
stime, cutime, and cstime are set to 0 [see times].
The time left until an alarm clock signal is reset to 0.
The set of signals pending for the child process is
initialized to the empty set.
Record locks set by the parent process are not inherited
by the child process [see fcntl(2)].
LWPs waiting on a synchronization queue may not be in
the same order in the child process, but the order of
release of LWPs from a synchronization object is
scheduling policy-specific. If FIFO ordering on a
synchronization object is required, it is called out in
the specification of that object.
The fork1 system call will create a new process with a single,
multiplexed (that is, not bound) thread. The new process has
a single LWP. The parent process is not changed.
The fork1 system call should be used by multithreaded process
that intend to have the new process call the exec system call.
Since exec will terminate all but one thread, there is no need
to duplicate all threads with forkall.
Copyright 1994 Novell, Inc. Page 2
fork(2) fork(2)
Return Values
On success, fork returns 0 to the child process and returns
the process ID of the child process to the parent process. On
failure, fork returns a value of (pid_t)-1 to the parent
process, sets errno to identify the error, and no child
process is created.
Errors
In the following conditions, fork fails and sets errno to:
EAGAIN The system limit on number of LWPs per real
user-id would be exceeded if the call succeeds.
and the calling process does not have the
P_SYSOPS privilege. The system lacked the
necessary resources to create another process.
EAGAIN Total amount of system memory available when
reading via raw I/O is temporarily
insufficient.
EINTR A forkall has been interrupted by a forkall
executed by another thread in the process.
REFERENCES
alarm(2), exec(2), fcntl(2), getrlimit(2), nice(2), plock(2),
priocntl(2), ptrace(2), semop(2), shmop(2), signal(2),
system(3S), times(2), umask(2), wait(2)
NOTICES
Considerations for Threads Programming
fork is synonymous with forkall.
Threads in the creating process are unaffected by these system
calls except possibly for the error indication EINTR in the
creating process.
It is expected that processes created via fork1 (only the
calling thread replicated) will soon call exec(2) to redefine
the address space. The single remaining thread should take
care when requesting resources (for example, locks) that were
duplicated from the parent. The fork1 system call does
duplicate the lock (part of the address space) but not the
thread that may have been holding that lock at the time of the
system call. The surviving thread would block forever since
there is no thread to release the resource.
Copyright 1994 Novell, Inc. Page 3