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