vfork(2) System Calls vfork(2)
vfork - spawn new process in a virtual memory efficient way
The vfork() function creates a new process without fully copying the
address space of the old process. This function is useful in instances
where the purpose of a fork(2) operation is to create a new system con-
text for an execve() operation (see exec(2)).
Unlike with the fork() function, the child process borrows the parent's
memory and thread of control until a call to execve() or an exit
(either abnormally or by a call to _exit() (see exit(2)). Any modifica-
tion made during this time to any part of memory in the child process
is reflected in the parent process on return from vfork(). The parent
process is suspended while the child is using its resources.
In a multithreaded application, vfork() borrows only the thread of
control that called vfork() in the parent; that is, the child contains
only one thread. The use of vfork() in multithreaded applications, how-
ever, is unsafe due to race conditons that can cause the child process
to become deadlocked and consequently block both the child and parent
process from execution indefinitely.
The vfork() function can normally be used the same way as fork(). The
procedure that called vfork(), however, should not return while running
in the child's context, since the eventual return from vfork() in the
parent would be to a stack frame that no longer exists. The _exit()
function should be used in favor of exit(3C) if unable to perform an
execve() operation, since exit() will invoke all functions registered
by atexit(3C) and will flush and close standard I/O channels, thereby
corrupting the parent process's standard I/O data structures. Care must
be taken in the child process not to modify any global or local data
that affects the behavior of the parent process on return from vfork(),
unless such an effect is intentional.
The vfork() function is deprecated. Its sole legitimate use as a pre-
lude to an immediate call to a function from the exec family can be
achieved safely by posix_spawn(3C) or posix_spawnp(3C).
Upon successful completion, vfork() returns 0 to the child process and
returns the process ID of the child process to the parent process. Oth-
erwise, -1 is returned to the parent process, no child process is cre-
ated, and errno is set to indicate the error.
The vfork() function will fail if:
EAGAIN The system-imposed limit on the total number of pro-
cesses under execution (either system-quality or by a
single user) would be exceeded. This limit is deter-
mined when the system is generated.
ENOMEM There is insufficient swap space for the new process.
See attributes(5) for descriptions of the following attributes:
tab() allbox; cw(2.750000i)| cw(2.750000i) lw(2.750000i)|
lw(2.750000i). ATTRIBUTE TYPEATTRIBUTE VALUE Interface StabilityObso-
exec(2), exit(2), fork(2), ioctl(2), atexit(3C), exit(3C),
posix_spawn(3C), posix_spawnp(3C), signal.h(3HEAD), wait(3C),
To avoid a possible deadlock situation, processes that are children in
the middle of a vfork() are never sent SIGTTOU or SIGTTIN signals;
rather, output or ioctls are allowed and input attempts result in an
To forstall parent memory corruption due to race conditions with signal
handling, vfork() treats signal handlers in the child process in the
same manner as the exec(2) functions: signals set to be caught by the
parent process are set to the default action (SIG_DFL) in the child
process (see signal.h(3HEAD)). Any attempt to set a signal handler in
the child before execve() to anything other than SIG_DFL or SIG_IGN is
disallowed and results in setting the handler to SIG_DFL.
On some systems, the implementation of vfork() causes the parent to
inherit register values from the child. This can create problems for
certain optimizing compilers if <<unistd.h>> is not included in the
source calling vfork().
SunOS 5.10 8 Nov 2004 vfork(2)