Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!snorkelwacker!spdcc!merk!alliant!cairo!tony
From: tony@cairo.UUCP (Tony Anzelmo)
Newsgroups: comp.arch
Subject: Re: Why fork? (long, was Re: IBM PC prehistory)
Message-ID: <122@cairo.UUCP>
Date: 17 Jan 90 13:38:19 GMT
References: <610@ssp11.idca.tds.philips.nl> <952@dms.UUCP> <1239@cirrusl.UUCP>
Reply-To: tony@cairo.UUCP (Tony Anzelmo)
Organization: Anzelmo Associates, Inc.
Lines: 33

In article <1239@cirrusl.UUCP> pete@cirrusl (Pete Carpenter) writes:
>In article <952@dms.UUCP> albaugh@dms.UUCP (Mike Albaugh) writes:
>>
>>	SO--- Why do we _still_ use fork() for all these near-trivial
>>cases.  [stuff deleted]
>
>>1) It can be used for part of spawn _and_ for actual task-splitting
>>	(problem subdivision). Why have two calls when one will do?
>>
>
>Actually, the Berkley folks have a system call vfork(), which does the 
>fork/exec in one operation. But of course, it is not compatible with Sys V.
              ^^^

Vfork does not do fork/exec in "one" operation. It simply avoids copying
the parent's address space to the child on the assumption that the child
will invoke exec (and therefore replace that address space). The parent
loans its address space to the child until an execve (or exit) is performed
by the child. During this time, the parent is suspended while the child
uses its address space.

There are also some strange anomalies with vfork (as compared to fork). One
of the more interesting ones is the ability of the child to modify the
parent's address space such that the parent sees those changes upon resumption.
Since the original intent of vfork was to provide an "efficient" fork, some
vendors have eliminated it by using "copy-on-write" in their fork
implementations. This technique reduces the address space copying to only
portions that are written and amortizes those costs across the child (and
parent) execution. However, the subtle semantic of vfork with regard to
the anomaly mentioned above is lost.


Tony Anzelmo