Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!sdd.hp.com!elroy.jpl.nasa.gov!lll-winken!sun-barr!ccut!titcca!cc.titech.ac.jp!necom830!mohta
From: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
Newsgroups: comp.arch
Subject: vfork (was Re: Paging page tables)
Message-ID: <5830@titcce.cc.titech.ac.jp>
Date: 11 Jul 90 03:43:55 GMT
References: <920@dgis.dtic.dla.mil>
Sender: news@cc.titech.ac.jp
Organization: Tokyo Institute of Technology
Lines: 33

In article <920@dgis.dtic.dla.mil>
	jkrueger@dgis.dtic.dla.mil (Jon) writes:

>>With copy-on-write scheme, a page need swap space
>>when the page is written something.

>But not until.  Page and swap file space allocation is as postponeable
>as the memory copy.

NO.

>>If you think virtual memory is free and allow forking without reserving
>>actual swap space, when  swap space is required, it is often the case
>>that, there is no free swap space, anymore.

>That way lies MVS, friends;

OK, if you love MVS, use it.

As for UNIX, there are three alternatives to treat forking:

1) An utterly broken implementation where some important system
process (such as inetd, ypbind or sendmail) may killed if there
is not enough swap space.

2) A crippled implementation where a large process can not fork-exec.

3) A healthy, effecient and easy implementation with vfork.

You, as a lover of MVS, seems to like 2), but, I, as a UNIX user,
like 3).

						Masataka Ohta