Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 (Tek) 9/28/84 based on 9/17/84; site motel6.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!ihnp4!alberta!ubc-vision!uw-beaver!tektronix!reed!motel6!keith From: keith@motel6.UUCP (Keith Packard) Newsgroups: net.unix-wizards Subject: Re: vfork Message-ID: <177@motel6.UUCP> Date: Wed, 10-Jul-85 21:19:03 EDT Article-I.D.: motel6.177 Posted: Wed Jul 10 21:19:03 1985 Date-Received: Sat, 13-Jul-85 10:02:58 EDT References: <726@wlcrjs.UUCP> <22500003@ima.UUCP> Reply-To: keith@motel6.UUCP (Keith Packard) Organization: 5440 SE 41st, Portland, OR Lines: 30 Summary: In article <22500003@ima.UUCP> johnl@ima.UUCP writes: > >/* 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 No, it's not because the segments are too large. It's because you must have contiguous physical addressing on the pdp, otherwise swapping becomes a nightmare (very important on pdp's remember) and physical i/o becomes impossible (only the cpu goes through the virtual memory map, not the i/o devices). many portions of the kernel depend on contiguous physical addresses of unix processes; true copy-on-touch demands *real* virtual memory. keith packard speaker-to-pdp ...!tektronix!reed!motel6!keith ...!tektronix!azure!keithp