Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!uwvax!oddjob!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.questions
Subject: Re: Fork and Join, Pipe in C
Message-ID: <7272@mimsy.UUCP>
Date: Tue, 30-Jun-87 21:57:50 EDT
Article-I.D.: mimsy.7272
Posted: Tue Jun 30 21:57:50 1987
Date-Received: Thu, 2-Jul-87 00:40:50 EDT
References: <7737@brl-adm.ARPA>, <1186@ius2.cs.cmu.edu> <8174@utzoo.UUCP> <113@xyzzy.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 45

>>guy%gorodish@Sun.COM (Guy Harris)
>>The only remaining reason to use vfork is that one has written ugly
>>and brain-damaged code that depends on the semantics of "vfork".

In article <113@xyzzy.UUCP> throopw@xyzzy.UUCP (Wayne A. Throop) writes:
>But fork() can *never* be as efficent as vfork(), and sometimes this
>efficency is crucial.

I disagree with the first part of this statement.  If you wish to
claim that on a Vax or other conventional two-level page table
architecture, fork() cannot be as efficient as vfork(), *that* I
can believe.  On the MIPS R2000, I think a copy-on-write fork()
could be just as efficient.

>Even if you can create copy-on-demand during fork(), the database
>needed to keep track of these pages consumes kernel (possibly virtual)
>memory space, and the creation and upkeep of this data consumes
>kernel CPU time.

What database?  Obviously you are considering some particular
implementation.  There are no doubt others, in which this operation
is almost free---costing about the same as vfork().

>The vfork() is hinting to the kernel that an exec() is about to
>occur, and therefore the kernel is well-advised not to invest much
>in the correct copy of the address space.

True; but one could consider *all* forks a hint that an exec() is
soon to occur, and arrange not to run the parent for several
milliseconds while the child finishes its task and exec()s.  In
effect, you would be making all forks vforks, since vfork really
works by suspending the parent, but you would do it without the
unintentionally shared memory.  (Vfork also avoids copying both
pages and PTEs, whereas even copy-on-write fork must copy PTEs.
But who says machines even *have* PTEs?)

>That said, I agree that vfork is a horrible kludge.  What *should* have
>been coined is the ability to create a process running a new executable
>image in a single system call.

As others have said, the big problem here is the need to alter some
of the per-process information before running the new image.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain:	chris@mimsy.umd.edu	Path:	seismo!mimsy!chris