qfork()

Richard Tobin richard at aiai.ed.ac.uk
Tue Jan 15 07:14:05 AEST 1991


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

In article <16895 at cs.utexas.edu> jfh at 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 at uk.ac.ed             
AI Applications Institute,           ARPA:  R.Tobin%uk.ac.ed at nsfnet-relay.ac.uk
Edinburgh University.                UUCP:  ...!ukc!ed.ac.uk!R.Tobin

Volume-Number: Volume 22, Number 70



More information about the Comp.std.unix mailing list