| Skip Navigation Links | |
| Exit Print View | |
![]() | man pages section 2: System Calls Oracle Solaris 11 Information Library |
- create a new process
#include <sys/types.h>#include <unistd.h>pid_tfork(void);
pid_tfork1(void);
pid_tforkall(void);
#include <sys/fork.h>pid_tforkx(intflags);
pid_tforkallx(intflags);
Thefork(),fork1(),forkall(),forkx(), andforkallx() functions create a new process.The address space of the new process (child process) is an exactcopy of the address space of the calling process (parent process). The childprocess 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 (seeexec(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 (seenice(2))
scheduler class (seepriocntl(2))
all attached shared memory segments (seeshmop(2))
process group ID -- memory mappings (seemmap(2))
session ID (seeexit(2))
current working directory
root directory
file mode creation mask (seeumask(2))
resource limits (seegetrlimit(2))
controlling terminal
saved user ID and group ID
task ID and project ID
processor bindings (seeprocessor_bind(2))
processor set bindings (seepset_bind(2))
process privilege sets (seegetppriv(2))
process flags (seegetpflags(2))
active contract templates (seecontract(4))
Scheduling priority and any per-process scheduling parameters that are specific to agiven scheduling class might or might not be inherited according to thepolicy of that particular class (seepriocntl(2)). The child process might ormight not be in the same process contract as the parent (seeprocess(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 ofshm_nattach is incremented by 1.
Allsemadj values are cleared (seesemop(2)).
Process locks, text locks, data locks, and other memory locks are not inherited by the child (seeplock(3C) andmemcntl(2)).
The child process'stms structure is cleared:tms_utime,stime,cutime, andcstime are set to 0 (seetimes(2)).
The child processes resource utilizations are set to 0; seegetrlimit(2). Theit_value andit_interval values for theITIMER_REAL timer are reset to 0; seegetitimer(2).
The set of signals pending for the child process is initialized to the empty set.
Timers created bytimer_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 tranlsation sizes (seememcntl(2)) are inherited by the child.
The child process holds no contracts (seecontract(4)).
Record locks set by the parent process are not inherited by thechild process (seefcntl(2)).
Although any open door descriptors in the parent are shared by thechild, only the parent will receive a door invocation from clients evenif the door descriptor is open in the child. If a descriptoris closed in the parent, attempts to operate on the door descriptorwill fail even if it is still open in the child.
A call toforkall() orforkallx() replicates in the child process allof the threads (seethr_create(3C) andpthread_create(3C)) in the parent process. Acall tofork1() orforkx() replicates only the calling thread in thechild process.
A call tofork() is identical to a call tofork1(); onlythe calling thread is replicated in the child process. This is thePOSIX-specified behavior forfork().
In releases of Solaris prior to Solaris 10, the behavior offork()depended on whether or not the application was linked with the POSIXthreads library. When linked with-lthread (Solaris Threads) but not linked with-lpthread (POSIX Threads),fork() was the same asforkall(). When linkedwith-lpthread, whether or not also linked with-lthread,fork() was thesame asfork1().
Prior to Solaris 10, either-lthread or-lpthread was required for multithreadedapplications. This is no longer the case. The standard C library providesall threading support for both sets of application programming interfaces. Applicationsthat require replicate-all fork semantics must callforkall() orforkallx().
Theforkx() andforkallx() functions accept aflags argument consisting of abitwise inclusive-OR of zero or more of the following flags, which aredefined in the header<sys/fork.h>:
Do not post aSIGCHLD signal to the parent process when the child process terminates, regardless of the disposition of theSIGCHLD 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 inwait(),waitid(P_ALL), orwaitid(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 inwaitid(P_PID,pid), is allowed and it is required, else when the child exits it will remain a zombie until the parent exits.
If theflags argument is 0forkx() is identical tofork() andforkallx() is identical toforkall().
If a multithreaded application callsfork(),fork1(), orforkx(), and the childdoes more than simply call one of theexec(2) functions, there isa possibility of deadlock occurring in the child. The application should usepthread_atfork(3C) to ensure safety with respect to this deadlock. Should there be anyoutstanding mutexes throughout the process, the application should callpthread_atfork() to waitfor and acquire those mutexes prior to callingfork(),fork1(), orforkx(). See “MT-Level of Libraries” on theattributes(5) manual page.
Thepthread_atfork() mechanism is used to protect the locks thatlibc(3LIB) usesto implement interfaces such asmalloc(3C). All interfaces provided bylibcare safe to use in a child process following afork(), exceptwhenfork() is executed within a signal handler.
The POSIX standard (seestandards(5)) requires fork to be Async-Signal-Safe (seeattributes(5)).This cannot be made to happen with fork handlers in place, becausethey acquire locks. To be in nominal compliance, no fork handlers arecalled whenfork() is executed within a signal context. This leaves thechild process in a questionable state with respect to its locks, butat least the calling thread will not deadlock itself attempting to acquirea lock that it already owns. In this situation, the applicationshould strictly adhere to the advice given in the POSIX specification: “To avoiderrors, the child process may only execute Async-Signal-Safe operations until such timeas one of theexec(2) functions is called.”
Upon successful completion,fork(),fork1(),forkall(),forkx(), andforkallx() return0 tothe child process and return the process ID of the child process tothe parent process. Otherwise,(pid_t)-1 is returned to the parent process, nochild process is created, anderrno is set to indicate the error.
Thefork(),fork1(),forkall(),forkx(), andforkallx() functions will fail if:
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.
Theforkx() andforkallx() functions will fail if:
Theflags argument is invalid.
Seeattributes(5) for descriptions of the following attributes:
|
Forfork(), seestandards(5).
alarm(2),exec(2),exit(2),fcntl(2),getitimer(2),getrlimit(2),memcntl(2),mmap(2),nice(2),priocntl(2),semop(2),shmop(2),times(2),umask(2),waitid(2),door_create(3C),exit(3C),plock(3C),pthread_atfork(3C),pthread_create(3C),signal(3C),system(3C),thr_create(3C)timer_create(3C),wait(3C),contract(4),process(4),attributes(5),privileges(5),standards(5)
An application should call_exit() rather thanexit(3C) if it cannotexecve(),sinceexit() will flush and close standard I/O channels and thereby corrupt theparent process's standard I/O data structures. Usingexit(3C) will flush buffered datatwice. Seeexit(2).
The thread in the child that callsfork(),fork1(), orfork1x() mustnot depend on any resources held by threads that no longer existin the child. In particular, locks held by these threads will notbe released.
In a multithreaded process,forkall() in one thread can cause blocking systemcalls to be interrupted and return with anEINTR error.
Copyright © 2011, Oracle and/or its affiliates. All rights reserved.Legal Notices | ![]() ![]() |