vfork - create a child process and block parent


       #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 mod­
       ifies 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.


       EAGAIN Too many processes - try again.

       ENOMEM There is insufficient swap space for the  new  pro­


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

       vfork() is a special case of clone(2).  It is used to cre­
       ate new processes 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.


       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 structure for the child.  How­
       ever,  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
       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 variables are held in a


       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 pos­
       sible  deadlock  situation, processes that are children in
       the middle of a vfork are never sent  SIGTTOU  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/ker­
       nel/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  indepen­
       dent 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  com­
       pliant.  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)