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

FreeBSD Manual Pages


home | help
vfork(2)			 System	Calls			      vfork(2)

       vfork - spawn new process in a virtual memory efficient way

       #include	<unistd.h>

       pid_t vfork(void);

       The  vfork()  function  creates a new process without fully copying the
       address space of	the old	process. This function is useful in  instances
       where the purpose of a fork(2) operation	is to create a new system con-
       text for	an execve() operation (see exec(2)).

       Unlike with the fork() function,	the child process borrows the parent's
       memory  and  thread of control until a call to execve() or an exit (ei-
       ther abnormally or by a call to _exit() (see exit(2)). Any modification
       made during this	time to	any part of memory in the child	process	is re-
       flected in the parent  process  on  return  from	 vfork().  The	parent
       process is suspended while the child is using its resources.

       In  a  multithreaded  application,   vfork() borrows only the thread of
       control that called vfork() in the parent; that is, the child  contains
       only one	thread.	The use	of vfork() in multithreaded applications, how-
       ever, is	unsafe due to race conditons that can cause the	child  process
       to  become  deadlocked and consequently block both the child and	parent
       process from execution indefinitely.

       The vfork() function can	normally be used the same way as  fork().  The
       procedure that called vfork(), however, should not return while running
       in the child's context, since the eventual return from vfork()  in  the
       parent  would  be  to  a	stack frame that no longer exists. The _exit()
       function	should be used in favor	of exit(3C) if unable  to  perform  an
       execve()	 operation,  since exit() will invoke all functions registered
       by atexit(3C) and will flush and	close standard I/O  channels,  thereby
       corrupting the parent process's standard	I/O data structures. Care must
       be taken	in the child process not to modify any global  or  local  data
       that affects the	behavior of the	parent process on return from vfork(),
       unless such an effect is	intentional.

       The vfork() function is deprecated. Its sole legitimate use as  a  pre-
       lude  to	 an  immediate	call to	a function from	the exec family	can be
       achieved	safely by posix_spawn(3C) or posix_spawnp(3C).

       Upon successful completion, vfork() returns  0 to the child process and
       returns the process ID of the child process to the parent process. Oth-
       erwise, -1 is returned to the parent process, no	child process is  cre-
       ated, and errno is set to indicate the error.

       The vfork() function will fail if:

       EAGAIN	       The  system-imposed  limit  on the total	number of pro-
		       cesses under execution (either system-quality or	 by  a
		       single  user)  would  be	exceeded. This limit is	deter-
		       mined when the system is	generated.

       ENOMEM	       There is	insufficient swap space	for the	new process.

       See attributes(5) for descriptions of the following attributes:

       |      ATTRIBUTE	TYPE	     |	    ATTRIBUTE VALUE	   |
       |Interface Stability	     |Obsolete			   |
       |MT-Level		     |Unsafe			   |

       exec(2),	  exit(2),   fork(2),	 ioctl(2),    atexit(3C),    exit(3C),
       posix_spawn(3C),	  posix_spawnp(3C),   signal.h(3HEAD),	wait(3C),  at-
       tributes(5), standards(5)

       To avoid	a possible 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
       EOF indication.

       To forstall parent memory corruption due	to race	conditions with	signal
       handling, vfork() treats	signal handlers	in the child  process  in  the
       same  manner  as	the exec(2) functions: signals set to be caught	by the
       parent process are set to the default action  (SIG_DFL)	in  the	 child
       process	(see signal.h(3HEAD)).	Any attempt to set a signal handler in
       the child before	execve() to anything other than	SIG_DFL	or SIG_IGN  is
       disallowed and results in setting the handler to	SIG_DFL.

       On some systems,	the implementation of vfork() causes the parent	to in-
       herit register values from the child. This can create problems for cer-
       tain  optimizing	 compilers if <unistd.h> is not	included in the	source
       calling vfork().

SunOS 5.10			  8 Nov	2004			      vfork(2)


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

home | help