*BSD News Article 27923


Return to BSD News archive

Path: sserve!newshost.anu.edu.au!munnari.oz.au!bruce.cs.monash.edu.au!harbinger.cc.monash.edu.au!yeshua.marcam.com!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!usenet.ins.cwru.edu!nigel.msen.com!math.fu-berlin.de!zib-berlin.de!netmbx.de!Germany.EU.net!news
From: bs@Germany.EU.net (Bernard Steiner)
Newsgroups: comp.os.386bsd.development
Subject: Re: Notes on the *new* FreeBSD V1.1 VM system
Date: 2 Mar 1994 11:11:49 +0100
Organization: EUnet Deutschland GmbH, Dortmund, Germany
Lines: 17
Distribution: world
Message-ID: <2l1op5$m6l@Germany.EU.net>
References: <CLutBp.4K9@flatlin.ka.sub.org> <RA0Jn4G.dysonj@delphi.com> <2kudpoINNbhd@CS.UTK.EDU> <1994Mar1.132637.58107@ans.net>
NNTP-Posting-Host: qwerty.germany.eu.net


In article <1994Mar1.132637.58107@ans.net>, dennis@ans.net (Dennis Ferguson) writes:
|> I don't think it is quite so easy, or clear.  Pages are explicitly
|> allocated by sbrk(), but are also implicitly and tentatively allocated
|> by fork().  If a 60 Mb process wants to fork() so it can execve() a small
|> shell command, do you really want to have to configure an extra 60 Mb
|> or more of swap space to allow this, or make the fork() fail if the
|> backing store for the entire extra 60 Mb isn't available?  With
|> copy-on-write fork()s a fork()-exec() is extremely likely to actually
|> use nearly none of that allocation, and I think you get a more useable
|> system if you don't demand that it be there.

Hmm. Excuse my ignorance, but isn't that what vfork() is for ?
Okay, I see the point in trying to do away with vfork(), but why not use it
while it's there ?

-Bernard