Sun Microsystems, Inc. gratefully acknowledges The Open Group for
permission to reproduce portions of its copyrighted documentation.
Original documentation from The Open Group can be obtained online at
http://www.opengroup.org/bookstore/.
The Institute of Electrical and Electronics Engineers and The Open
Group, have given us permission to reprint portions of their
documentation.
In the following statement, the phrase ``this text'' refers to portions
of the system documentation.
Portions of this text are reprinted and reproduced in electronic form
in the SunOS Reference Manual, from IEEE Std 1003.1, 2004 Edition,
Standard for Information Technology -- Portable Operating System
Interface (POSIX), The Open Group Base Specifications Issue 6,
Copyright (C) 2001-2004 by the Institute of Electrical and Electronics
Engineers, Inc and The Open Group. In the event of any discrepancy
between these versions 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.
This notice shall appear on any product containing this material.
The contents of this file are subject to the terms of the
Common Development and Distribution License (the "License").
You may not use this file except in compliance with the License.
You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
or http://www.opensolaris.org/os/licensing.
See the License for the specific language governing permissions
and limitations under the License.
When distributing Covered Code, include this CDDL HEADER in each
file and include the License file at usr/src/OPENSOLARIS.LICENSE.
If applicable, add the following below this CDDL HEADER, with the
fields enclosed by brackets "[]" replaced with your own identifying
information: Portions Copyright [yyyy] [name of copyright owner]
Copyright 1989 AT&T
Portions Copyright (c) 1994, X/Open Company Limited. All Rights Reserved.
Copyright (c) 2008, Sun Microsystems, Inc. All Rights Reserved.
Copyright 2024 Oxide Computer Company
#include <sys/types.h> #include <unistd.h> pid_t fork(void);
pid_t fork1(void);
pid_t forkall(void);
#include <sys/fork.h> pid_t forkx(int flags);
pid_t forkallx(int flags);
real user ID, real group ID, effective user ID, effective group ID
environment
open file descriptors (except those marked close-on-fork, see discussion below)
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
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(5))
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(5)). 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. In addition, any file descriptors that were marked with the close-on-fork flag, FD_CLOFORK (see fcntl(2) and O_CLOFORK in open(2)), will not be present in the child process, but remain open in 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 getrlimit(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(3C) are not inherited by the child process.
No asynchronous input or asynchronous output operations are inherited by the child.
Any preferred hardware address translation sizes (see memcntl(2)) are inherited by the child.
The child process holds no contracts (see contract(5)).
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.
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 releases of Solaris prior to Solaris 10, 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().
Prior to Solaris 10, either -lthread or -lpthread was required for multithreaded applications. This is no longer the case. 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() or forkallx().
Do not post a SIGCHLD signal to the parent process when the child process terminates, regardless of the disposition of the SIGCHLD signal in the parent. SIGCHLD signals are still possible for job control stop and continue actions if the parent has requested them.
Do not allow wait-for-multiple-pids by the parent, as in wait(), waitid(P_ALL), or waitid(P_PGID), to reap the child and do not allow the child to be reaped automatically due the disposition of the SIGCHLD signal being set to be ignored in the parent. Only a specific wait for the child, as in waitid(P_PID, pid), is allowed and it is required, else when the child exits it will remain a zombie until the parent exits.
If the flags argument is 0 forkx() is identical to fork() and forkallx() is identical to forkall().
The pthread_atfork() mechanism is used to protect the locks that libc(3LIB) uses to implement interfaces such as malloc(3C). All interfaces provided by libc are safe to use in a child process following a fork(), except when fork() is executed within a signal handler.
The POSIX standard (see standards(7)) requires fork to be Async-Signal-Safe (see attributes(7)). This cannot be made to happen with fork handlers in place, because they acquire locks. To be in nominal compliance, no fork handlers are called when fork() is executed within a signal context. This leaves the child process in a questionable state with respect to its locks, but at least the calling thread will not deadlock itself attempting to acquire a lock that it already owns. In this situation, the application should strictly adhere to the advice given in the POSIX specification: "To avoid errors, the child process may only execute Async-Signal-Safe operations until such time as one of the exec(2) functions is called."
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.
There is not enough swap space.
The {PRIV_PROC_FORK} privilege is not asserted in the effective set of the calling process.
The forkx() and forkallx() functions will fail if: EINVAL
The flags argument is invalid.
| ATTRIBUTE TYPE ATTRIBUTE VALUE |
| Interface Stability Committed |
| MT-Level Async-Signal-Safe. |
| Standard See below. |
For fork(), see standards(7).
The thread in the child that calls fork(), fork1(), or fork1x() 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.