Path: utzoo!censor!geac!torsqnt!hybrid!scifi!bywater!uunet!cs.utexas.edu!jsq
From: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
Newsgroups: comp.std.unix
Subject: Re: qfork()
Message-ID: <17599@cs.utexas.edu>
Date: 3 Feb 91 12:54:51 GMT
References: <16213@cs.utexas.edu> <16483@cs.utexas.edu> <16522@cs.utexas.edu> <16873@cs.utexas.edu> <16895@cs.utexas.edu> <16994@cs.utexas.edu>
Sender: jsq@cs.utexas.edu
Organization: Tokyo Institute of Technology
Lines: 29
Approved: jsq@cs.utexas.edu (Moderator, John S. Quarterman)
X-Submissions: std-unix@uunet.uu.net

Submitted-by: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)

In article <16994@cs.utexas.edu>
	richard@aiai.ed.ac.uk (Richard Tobin) writes:

>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.

That is the case where COW fork() with late allocation of pages or
vfork() must be used.

>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.

If fork() is used as a real fork(), it is very probable that it modifies
its data space many times.

The severe problem is that the program can not control the failure.
It immediately dies.

With non-COW fork() or COW fork() with immediate allocation of pages,
such a failure can be detected as error return value of fork()
and may be processed in a controlled fashion.

					Masataka Ohta

Volume-Number: Volume 22, Number 101