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