vfork (2)


       vfork - create a child process and block parent


       #include <sys/types.h>
       #include <unistd.h>

       pid_t vfork(void);


       (From  XPG4  / SUSv2 / POSIX draft.)  The vfork() function has the same
       effect as fork(), except that the behaviour is undefined if the process
       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  func-


       EAGAIN Too many processes - try again.

       ENOMEM There is insufficient swap space for the new process.


       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 mem-
       ory  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.


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


       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.


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


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

Linux 2.2.0                       1999-11-01                          vfork(2)