VFORK(2) System Calls VFORK(2)

NAME

vfork, vforkx - spawn new process in a virtual memory efficient way

SYNOPSIS

#include <unistd.h>

pid_t
vfork(void);

#include <sys/fork.h>

pid_t
vforkx(int flags);

DESCRIPTION

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 exec(2) operation.

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(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 resources.

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 applications, however, is unsafe due to race conditions that
can cause the child process to become deadlocked and consequently block
both the child and parent process from execution indefinitely.

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, 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(2) family
can be achieved safely by posix_spawn(3C) or posix_spawnp(3C).

Fork Extensions

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

FORK_NOSIGCHLD
FORK_WAITPID

See fork(2) for descriptions of these flags. If the flags argument is 0,
vforkx() is identical to vfork().

RETURN VALUES

Upon successful completion, vfork() and vforkx() return 0 to the child
process and return 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.

ERRORS

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 process.

The vforkx() function will fail if:

EINVAL The flags argument is invalid.

INTERFACE STABILITY

The vfork() function is Obsolete Standard.

The vforkx() function is Obsolete Uncommitted.

MT-LEVEL
Unsafe.

SEE ALSO

exec(2), exit(2), fork(2), ioctl(2), atexit(3C), exit(3C), posix_spawn(3C),
posix_spawnp(3C), wait(3C), signal.h(3HEAD), standards(7)

NOTES

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 vforkx().

STANDARDS

The vfork() function is available in the following compilation
environments. See standards(7).

+o X/Open Portability Guide Issue 4, Version 2 ("XPG4.2")
+o Version 2 of the Single UNIX Specification ("SUSv2")
+o Version 3 of the Single UNIX Specification ("SUSv3")

It was marked obsolete in Version 3 of the Single UNIX Specification
("SUSv3") and removed from IEEE Std 1003.1-2008 ("POSIX.1").

The vforkx() function is a local extension and not available in any
strictly standards-compliant compilation environment.

illumos August 20, 2014 illumos