vfork()

[Ralf U. Holighaus]

pfalstad at phoenix.Princeton.EDU (Paul Falstad) writes:

>>Actually with vfork, the sun process shares text and data with the father
>>process, so the only thing possible after a vfork is either an exit by
>>the father or an exec by the son. Any other use will cause garbage, be-
>>cause neither of the two processes has a data rang for it's own.

>Not true.  The parent cannot exit because it's not running; it waits for the
>child to exit or exec first.  The child can do whatever it wants to the
>parent's data segment before it exit()s or exec()s (except destroy the
>parent's stack frame) without causing garbage.  You could even use this call
>for a horribly unportable shared memory hack if you wanted.


     VFORK(2)			   HP-UX		      VFORK(2)




     NAME
	  vfork	- spawn	new process in a virtual memory	efficient way

     SYNOPSIS
	  int vfork()

     REMARKS
	  Vfork	is provided as a higher	performance version of fork on
	  those	systems	which choose to	provide	it and for which there
	  is a performance advantage.

	  Vfork	differs	from fork only in that the child  process  may
	  share	 code  and  data  with	the  calling  process  (parent
	  process).  This speeds the cloning activity significantly at
	  a  risk  to  the integrity of	the parent process if vfork is
	  misused.

	  The use of vfork for any purpose except as a prelude	to  an
	  immediate  exec or exit is not supported.  Any program which
	  relies upon the differences between fork and	vfork  is  not
	  portable across HP-UX	systems.

	  All implementations of HP-UX must provide the	 entry	vfork,
	  but  it  is  permissible for them to treat it	identically to
	  fork.	 Some implementations may not  choose  to  distinguish
	  the two because their	implementation of fork is as efficient
	  as possible, and others may not  wish	 to  carry  the	 added
	  overhead of two similar calls.

     DESCRIPTION
	  Vfork	can be used to	create	new  processes	without	 fully
	  copying  the	address	space of the old process.  If a	forked
	  process is simply going to do	an  exec(2),  the  data	 space
	  copied  from the parent to the child by fork(2) is not used.
	  This is particularly inefficient  in	a  paged  environment.
	  Vfork	 is  useful  in	this case.  Depending upon the size of
	  the  parent's	 data  space,  it  can	give   a   significant
	  performance improvement over fork.

	  Vfork	differs	from  fork  in	that  the  child  borrows  the
	  parent's  memory  and	thread of control until	a call to exec
	  or an	exit (either by	a call to exit(2) or abnormally.)  The
	  parent  process  is  suspended  while	the child is using its
	  resources.

	  Vfork	can normally be	used just like fork. It	does not work,
	  however, to return while running in the child's context from
	  the procedure	which called vfork since the  eventual	return



     Hewlett-Packard Company	   - 1 -   Version B.1,	  Mar 10, 1989






     VFORK(2)			   HP-UX		      VFORK(2)




	  from	vfork  would then return to a no longer	existent stack
	  frame.  Be careful, also, to call exit rather than exit  if
	  you  cannot  exec,  since exit will flush and	close standard
	  I/O channels,	and  thereby  mess  up	the  parent  process's
	  standard  I/O	 data structures.  (Even with fork it is wrong
	  to call exit since  buffered	data  would  then  be  flushed
	  twice.)

	  The [vfork,exec] window begins at the	vfork  call  and  ends
	  when the child completes its exec call.

     RETURN VALUE
	  Upon successful completion, vfork returns a value  of	 0  to
	  the  child  process  and returns the process ID of the child
	  process to the parent	process.  Otherwise, a value of	-1  is
	  returned  to	the  parent,  no child process is created, and
	  errno	is set to indicate the error.

     ERRORS
	  Vfork	will fail and no child process will be created if  one
	  or more of the following are true:

	  [EAGAIN]	 The system-wide limit on the total number  of
			 processes under execution would be exceeded.

	  [EAGAIN]	 The system-imposed limit on the total	number
			 of processes under execution by a single user
			 would be exceeded.

     DEPENDENCIES
	  Series 300, 800
	       A call to signal(2) in the [vfork,exec] window which is
	       used  to	 catch	a  signal  can	affect handling	of the
	       signal by the parent.  This is not true if  the	signal
	       is set SIGDFL or SIGIGN, or if	sigvector(2) is	used.

	  Series 500
	       Shared  memory  segments	  generated   with   the   EMS
	       intrinsics will be inherited over vfork.	Private	memory
	       segments	will not be copied over	vfork.

	       Vfork will also fail in the following cases:

	       [ENOMEM]	      There is not enough physical  memory  to
			      create the new process.

	       [EAGAIN]	      The  child  process  attempts  to	 do  a
			      second  vfork  or	 a  fork  while	in the
			      [vfork,exec] window.

	       The parent and child processes  share  the  same	 stack



     Hewlett-Packard Company	   - 2 -   Version B.1,	  Mar 10, 1989






     VFORK(2)			   HP-UX		      VFORK(2)




	       space  within  the [vfork,exec] window.	If the size of
	       the stack has been changed within this  window  by  the
	       child  process  (return from or call to a function, for
	       example), it  is	 likely	 that  the  parent  and	 child
	       processes will be killed	with signal SIGSEGV.

	  Series 500, 800
	       Process times for the parent and	child processes	within
	       the [vfork,exec]	window may be inaccurate.

	  Series 800
	       The parent and child processes  share  the  same	 stack
	       space  within  the [vfork,exec] window.	If the size of
	       the stack has been changed within this  window  by  the
	       child  process  (return from or call to a function, for
	       example), it  is	 likely	 that  the  parent  and	 child
	       processes will be killed	with signal SIGSEGV or SIGBUS.

     AUTHOR
	  Vfork	 was  developed	 by  the  University  of   California,
	  Berkeley.

     SEE ALSO
	  exec(2), exit(2), fork(2), wait(2).

-- 
  PEM Programmentwicklungsgesellschaft    |         Ralf U. Holighaus
        fuer Microcomputer mbH            |         Technical Support
PO-Box 810165 D-7000 Stuttgart 80 Germany | holighaus at pemstgt.PEM-Stuttgart.de
VOICE: x49-711-713045 FAX: x49-711-713047 |       ..!unido!pemcom!ralfi