Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!mahendo!wlbr!WLV.IMSD.CONTEL.COM!sms
From: sms@WLV.IMSD.CONTEL.COM (Steven M. Schultz)
Newsgroups: comp.arch
Subject: Re: Why fork? (long, was Re: IBM PC prehistory)
Message-ID: <44375@wlbr.IMSD.CONTEL.COM>
Date: 19 Jan 90 00:23:11 GMT
References: <610@ssp11.idca.tds.philips.nl> <952@dms.UUCP> <1239@cirrusl.UUCP> <IC51D77xds13@ficc.uu.net>
Sender: news@wlbr.IMSD.CONTEL.COM
Reply-To: sms@WLV.IMSD.CONTEL.COM.UUCP (Steven M. Schultz)
Organization: Contel Federal Systems
Lines: 14

In article <IC51D77xds13@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>> 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.
>
>And of course once you have a VM system fork() is just fine and vfork() is
>a meaningless optimisation... So why didn't they put vfork() in 2BSD?

	They did.  Put vfork() in 2BSD that is.  Works very nicely too. 'vmstat'
	even reports how many forks() and vforks() were done along with the
	number (and averages) and amount of clicks of memory copied for each 
	type of fork.

	Steven M. Schultz
	sms@wlv.imsd.contel.com