Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!yale!husc6!encore!pinocchio.encore.com
From: jkenton@pinocchio.encore.com (Jeff Kenton)
Newsgroups: comp.arch
Subject: Re: fork, spawn, vfork: an overview
Message-ID: <12382@encore.Encore.COM>
Date: 6 Aug 90 01:42:37 GMT
References: <25904@mimsy.umd.edu>
Sender: news@Encore.COM
Lines: 35

From article <25904@mimsy.umd.edu>, by chris@mimsy.umd.edu (Chris Torek):
> Since there seems to be a great deal of confusion and ignorance
> surrounding the `vfork issue', it might help if I describe how these
> things work.
> 
>	[Good survey of the issues] 
> 
>                                                    On a machine like
> the Butterfly, a vfork helps because the parent process is suspended:
> the child can run in the parent's space until it exits or, more likely,
> gets another processor to do an exec.  In essence, vfork is `fork with
> a promise to finish soon' or even `spawn, but let me do a few things
> before I go'.

The one issue you haven't dealt with is the case where a program wants
to spawn many copies of itself but never execs after the fork.  In this
case you need a fork() which is biased toward moving to another processor
and has no way to guarantee the "child runs first" semantics (which the
man page warns against relying upon).  On the Butterfly, with >100 CPUs
and non-uniform memory, this is a reasonable scenario.  Traditional
vfork() buys very little, and it's ugly.

Beauty is only skin deep, but ugly goes right to the bone.








- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      jeff kenton  ---	temporarily at jkenton@pinocchio.encore.com	 
		   ---  always at (617) 894-4508  ---
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -