VFORK(2) | System Calls Manual | VFORK(2)

# NAME

`vfork` —
spawn new process in a virtual memory efficient way

# LIBRARY

Standard C Library (libc, -lc)

# SYNOPSIS

`#include <unistd.h>`

pid_t
`vfork`(void);

# DESCRIPTION

The `vfork` system call creates a new process that does not have a new virtual address space, but rather shares address space with the parent, thus avoiding potentially expensive copy-on-write operations normally associated with creating a new process. It is useful when the purpose of fork(2) would have been to create a new system context for an execve(2). The `vfork` system call differs from fork(2) in that the child borrows the parent's memory and thread of control until a call to execve(2) or an exit (either by a call to _exit(2) or abnormally). The parent process is suspended while the child is using its resources.

The `vfork` system call returns 0 in the child's context and (later) the pid of the child in the parent's context.

The `vfork` system call can normally be used just like fork(2). It does not work, however, to return while running in the child's context from the procedure that called `vfork`() since the eventual return from `vfork`() would then return to a no longer existing stack frame. Be careful, also, to call _exit(2) rather than exit(3) if you can't execve(2), since exit(3) will flush and close standard I/O channels, and thereby mess up the standard I/O data structures in the parent process. (Even with fork(2) it is wrong to call exit(3) since buffered data would then be flushed twice.)

# RETURN VALUES

Same as for fork(2).

# ERRORS

Same as for fork(2).

# SEE ALSO

execve(2), fork(2), sigaction(2), wait(2)

# HISTORY

The `vfork`() function call appeared in 3.0BSD. In 4.4BSD, the semantics were changed to only suspend the parent and not share the address space. The original semantics were reintroduced in NetBSD 1.4.

# BUGS

Portable applications should not depend on the memory sharing semantics of `vfork`() as implementations exist that implement `vfork`() as plain fork(2).

To avoid a possible deadlock situation, processes that are children in the middle of a `vfork`() are never sent `SIGTSTP`, `SIGTTOU` or `SIGTTIN` signals; rather, output or ioctl(2) calls are allowed and input attempts result in an end-of-file indication.

May 19, 2018 | NetBSD 9.4