Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: $Revision: 1.6.2.16 $; site ima.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!ima!johnl
From: johnl@ima.UUCP
Newsgroups: net.unix-wizards
Subject: Re: vfork
Message-ID: <22500003@ima.UUCP>
Date: Mon, 8-Jul-85 11:29:00 EDT
Article-I.D.: ima.22500003
Posted: Mon Jul  8 11:29:00 1985
Date-Received: Thu, 11-Jul-85 04:54:15 EDT
References: <726@wlcrjs.UUCP>
Lines: 16
Nf-ID: #R:wlcrjs:-72600:ima:22500003:000:749
Nf-From: ima!johnl    Jul  8 11:29:00 1985


/* Written  1:22 am  Jul  8, 1985 by thomas@utah-gr in ima:net.unix-wizards */
> The problem is that the initial design of the Vax (750?) had a flaw that
> made copy-on-write VERY difficult (impossible?) to do.  So, the vfork
> kludge was the only workable solution to avoid copying an entire process

No it wasn't -- vfork really has to be chalked up to laziness.  It would
have been entirely workable to do copy-on-touch in the stack segment (which
was where the copy-on-write pages didn't work.)  Considering how little
stack data is read but not written, the performance would have been about
the same.

On machines like the PDP-11, vfork makes more sense since the segments
are too big to do practical copy-on-anything.

John Levine, ima!johnl