Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!topaz.rutgers.edu!ron
From: ron@topaz.rutgers.edu (Ron Natalie)
Newsgroups: comp.unix.questions
Subject: Re: Fork and Join, Pipe in C
Message-ID: <13011@topaz.rutgers.edu>
Date: Mon, 29-Jun-87 12:10:19 EDT
Article-I.D.: topaz.13011
Posted: Mon Jun 29 12:10:19 1987
Date-Received: Tue, 30-Jun-87 05:53:00 EDT
References: <7737@brl-adm.ARPA>, <1186@ius2.cs.cmu.edu> <8174@utzoo.UUCP> <21685@sun.uucp> <113@xyzzy.UUCP>
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 20

> But fork() can *never* be as efficent as vfork(), and sometimes this
> efficency is crucial.  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.

Crap.  No extra space is involved as there are already unused bits in
the page tables in most implementations.  The few systems that already
do copy-on-write forking don't end up using any additional CPU time.
The MMU is what keeps track of write references (it is already doing
this for "references" without differentiating writes and reads).
What extra CPU overhead is it for machines that have decent virtual
memory.  VFORK exists only for people who don't share memory well in
hardware.

Note that FORK-AND-EXEC won't solve any but the most simple cases.
The csh needs to twiddle process groups and file descriptors after
the fork as do popen and other library calls.

-Ron