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