VFORK(2)		  Linux Programmer's Manual		     VFORK(2)



NAME
       vfork - create a child process and block parent

SYNOPSIS
       #include 
       #include 

       pid_t vfork(void);

STANDARD DESCRIPTION
       (From  XPG4 / SUSv2 / POSIX draft.)  The vfork() function has the same
       effect as fork(), except that the behaviour is undefined if  the	 pro-
       cess created by vfork() either modifies any data other than a variable
       of type pid_t used to store the return value from vfork(), or  returns
       from  the  function  in	which  vfork() was called, or calls any other
       function before successfully calling _exit() or one of the exec family
       of functions.

ERRORS
       EAGAIN Too many processes - try again.

       ENOMEM There is insufficient swap space for the new process.

LINUX DESCRIPTION
       vfork,  just like fork(2), creates a child process of the calling pro-
       cess.  For details and return value and errors, see fork(2).

       vfork() is a special case of clone(2).  It is used to create new	 pro-
       cesses  without copying the page tables of the parent process.  It may
       be useful in performance sensitive applications where a child will  be
       created which then immediately issues an execve().

       vfork()	differs	 from  fork in that the parent is suspended until the
       child makes a call to execve(2) or _exit(2).   The  child  shares  all
       memory  with its parent, including the stack, until execve() is issued
       by the child.  The child must not return from the current function  or
       call exit(), but may call _exit().

       Signal  handlers are inherited, but not shared.	Signals to the parent
       arrive after the child releases the parent.

HISTORIC DESCRIPTION
       Under Linux, fork() is implemented using copy-on-write pages,  so  the
       only  penalty  incurred	by  fork() is the time and memory required to
       duplicate the parent's page tables, and to create a unique task struc-
       ture  for  the  child.	However,  in  the bad old days a fork() would
       require making a complete copy of the caller's data space, often need-
       lessly,	since usually immediately afterwards an exec() is done. Thus,
       for greater efficiency, BSD introduced the vfork system call, that did
       not  fully  copy the address space of the parent process, but borrowed
       the parent's memory and thread of control until a call to execve()  or
       an exit occurred. The parent process was suspended while the child was
       using its resources.  The use of vfork was tricky - for	example,  not
       modifying  data	in the parent process depended on knowing which vari-
       ables are held in a register.

BUGS
       It is rather unfortunate that Linux  revived  this  spectre  from  the
       past.   The  BSD	 manpage states: "This system call will be eliminated
       when proper system sharing mechanisms are  implemented.	Users  should
       not  depend  on	the  memory sharing semantics of vfork as it will, in
       that case, be made synonymous to fork."

       Formally speaking, the standard description given above does not allow
       one  to	use  vfork() since a following exec might fail, and then what
       happens is undefined.

       Details of the signal handling are obscure and differ between systems.
       The  BSD manpage states: "To avoid a possible deadlock situation, pro-
       cesses that are children in the middle of a vfork are never sent SIGT-
       TOU or SIGTTIN signals; rather, output or ioctls are allowed and input
       attempts result in an end-of-file indication."

       Currently (Linux 2.3.25), strace(1) cannot follow vfork() and requires
       a kernel patch.

HISTORY
       The  vfork()  system  call appeared in 3.0BSD.  In BSD 4.4 it was made
       synonymous  to  fork(),	but   NetBSD   introduced   it	 again,	  cf.
       http://www.netbsd.org/Documentation/kernel/vfork.html  .	 In Linux, it
       has been equivalent to fork() until 2.2.0-pre6 or so. Since 2.2.0-pre9
       (on  i386, somewhat later on other architectures) it is an independent
       system call. Support was added in glibc 2.0.112.

CONFORMING TO
       The vfork call may be a bit similar to calls with  the  same  name  in
       other  operating	 systems.  The requirements put on vfork by the stan-
       dards are weaker than those put on fork, so  an	implementation	where
       the  two	 are  synonymous  is compliant. In particular, the programmer
       cannot rely on the parent remaining blocked until a call	 of  execve()
       or  _exit()  and	 cannot	 rely on any specific behaviour w.r.t. shared
       memory.

SEE ALSO
       clone(2), execve(2), fork(2), wait(2)



Linux 2.2.0			  1999-11-01			     VFORK(2)