Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
VFORK(2)		   Linux Programmer's Manual		      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
       process.	 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 du-
       plicate the parent's page tables, and to	create a unique	task structure
       for  the	 child.	  However,  in the bad old days	a fork() would require
       making a	complete copy of the caller's data  space,  often  needlessly,
       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 us-
       ing its resources.  The use of vfork was	tricky - for example, not mod-
       ifying  data  in	the parent process depended on knowing which variables
       are held	in a register.

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

       The  vfork()  system  call  appeared in 3.0BSD.	In BSD 4.4 it was made
       synonymous  to  fork(),	 but   NetBSD	introduced   it	  again,   cf.  .	  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)


Want to link to this manual page? Use this URL:

home | help