Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!bloom-beacon!bu.edu!rpi!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!jsq
From: richard@aiai.ed.ac.uk (Richard Tobin)
Newsgroups: comp.std.unix
Subject: Re: qfork()
Message-ID: <16994@cs.utexas.edu>
Date: 14 Jan 91 20:14:05 GMT
References: <16213@cs.utexas.edu> <16483@cs.utexas.edu> <16522@cs.utexas.edu> <16873@cs.utexas.edu> <16895@cs.utexas.edu>
Sender: jsq@cs.utexas.edu
Reply-To: richard@aiai.ed.ac.uk (Richard Tobin)
Organization: AIAI, University of Edinburgh, Scotland
Lines: 29
Approved: jsq@cs.utexas.edu (Moderator, John S. Quarterman)
X-Submissions: std-unix@uunet.uu.net

Submitted-by: richard@aiai.ed.ac.uk (Richard Tobin)

In article <16895@cs.utexas.edu> jfh@rpp386.cactus.org (John F Haugh II) writes:
>Any scenario where I do modify a page is unsuitable for vfork(), so there
>is no room for comparision of the merits of fork() with vfork().

Most programs that use vfork() change the values of variables in the
child.  This is perfectly reasonable, so long as the parent doesn't
rely on the value of those variables.

Of course, these programs don't usually change many variables, so a
copy-on-write fork() won't need many pages in this case.  A c-o-w	
fork() with late allocation of pages could could be as robust as
vfork() almost always by pre-allocating a few pages.

Surely the problem is when it's being used as a *real* fork(), and the
program fails much later when it modifies one variable too many.

I prefer to think of vfork() as being a way to save a process's kernel
state - file descriptors etc - and having that state automatically
restored when an exec() is done.

-- Richard
-- 
Richard Tobin,                       JANET: R.Tobin@uk.ac.ed             
AI Applications Institute,           ARPA:  R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk
Edinburgh University.                UUCP:  ...!ukc!ed.ac.uk!R.Tobin

Volume-Number: Volume 22, Number 70