System Calls vfork(2)
vfork, vforkx - spawn new process in a virtual memory effi-
pid_t vforkx(int flags);
The vfork() and vforkx() functions create a new process
without fully copying the address space of the old process.
These functions are useful in instances where the purpose of
a fork(2) operation is to create a new system context 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 modification made during this
time to any part of memory in the child process is reflected
in the parent process on return from vfork() or vforkx().
The parent process is suspended while the child is using its
In a multithreaded application, vfork() and vforkx() borrow
only the thread of control that called vfork() or vforkx()
in the parent; that is, the child contains only one thread.
The use of vfork() or vforkx() in multithreaded applica-
tions, however, is unsafe due to race conditions that can
cause the child process to become deadlocked and conse-
quently block both the child and parent process from execu-
The vfork() and vforkx() functions can normally be used the
same way as fork() and forkx(), respectively. The calling
procedure, however, should not return while running in the
child's context, since the eventual return from vfork() or
vforkx() 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,
SunOS 5.11 Last change: 13 Dec 2006 1
System Calls vfork(2)
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() or vforkx(),
unless such an effect is intentional.
Unlike fork() and forkx(), fork handlers are not run when
vfork() and vforkx() are called.
The vfork() and vforkx() functions are deprecated. Their
sole legitimate use as a prelude to an immediate call to a
function from the exec family can be achieved safely by
posix_spawn(3C) or posix_spawnp(3C).
The vforkx() function accepts a flags argument consisting of
a bitwise inclusive-OR of zero or more of the following
flags, which are defined in the header <sys/fork.h>:
See fork(2) for descriptions of these flags. If the flags
argument is 0, vforkx() is identical to vfork().
Upon successful completion, vfork() and vforkx() return 0 to
the child process and returns the process ID of the child
process to the parent process. Otherwise, -1 is returned to
the parent process, no child process is created, and errno
is set to indicate the error.
The vfork() and vforkx() functions will fail if:
EAGAIN The system-imposed limit on the total number of
processes under execution (either system-quality
or by a single user) would be exceeded. This limit
is determined when the system is generated.
ENOMEM There is insufficient swap space for the new pro-
The vforkx() function will fail if:
EINVAL The flags argument is invalid.
SunOS 5.11 Last change: 13 Dec 2006 2
System Calls vfork(2)
See attributes(5) for descriptions of the following attri-
| ATTRIBUTE TYPE | ATTRIBUTE VALUE |
| Interface Stability | Obsolete |
| MT-Level | Unsafe |
exec(2), exit(2), fork(2), ioctl(2), atexit(3C), exit(3C),
posix_spawn(3C), posix_spawnp(3C), signal.h(3HEAD),
wait(3C), attributes(5), standards(5)
To avoid a possible deadlock situation, processes that are
children in the middle of a vfork() or vforkx() are never
sent SIGTTOU or SIGTTIN signals; rather, output or ioctls
are allowed and input attempts result in an EOF indication.
To forestall parent memory corruption due to race conditions
with signal handling, vfork() and vforkx() treat 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() and vforkx()
cause 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() or
if <sys/fork.h> is not included in the source calling
SunOS 5.11 Last change: 13 Dec 2006 3
Man(1) output converted with