fork

, fork1

, forkall

- create a new process

Synopsis

#include <sys/types.h>
#include <unistd.h>
pid_tfork(void);

pid_tfork1(void);

pid_tforkall(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:

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 descriptors and directory streams. Each of the child's file descriptors shares a common file pointer with the corresponding file descriptor of the parent.

Each shared memory segment remains attached and the value of shm_nattach is incremented by 1.

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 multithreaded applications.
The standard C library provides all threading support for both sets of
application programming interfaces. Applications 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.

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.