Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!ptsfa!hoptoad!academ!killer!pollux!ti-csl!tifsie!kent
From: kent@tifsie.UUCP (Russell Kent)
Newsgroups: comp.arch,comp.unix.wizards,comp.os.minix
Subject: Re: UNIX fork
Message-ID: <246@tifsie.UUCP>
Date: Tue, 29-Sep-87 21:20:33 EDT
Article-I.D.: tifsie.246
Posted: Tue Sep 29 21:20:33 1987
Date-Received: Wed, 7-Oct-87 00:41:01 EDT
References: <125@quick.COM>
Organization: TI Process Automation Center, Dallas
Lines: 27
Xref: mnetor comp.arch:2485 comp.unix.wizards:4647 comp.os.minix:1784

in article <125@quick.COM>, srg@quick.COM (Spencer Garrett) says:
> Xref: tifsil comp.arch:734 comp.unix.wizards:1187 comp.os.minix:494
> 
> In article <7672@felix.UUCP>, preston@felix.UUCP (Preston Bannister) writes:
> } What I should have said :-) was that the
> } code executed between the fork() and exec() call typically does not
> } need the full semantics of fork().
> 
> Indeed it does not.  That's why Berkeley has vfork().  A vfork call
> "borrows" the parent's memory instead of copying it.

This (perhaps unfortunately) includes the information about open FILEs and
file descriptors, which precludes the redirection of the child's streams
without a good deal of work by the parent to recover.  Preston's objections
to the fork()/exec() concepts are valid; they glob together concepts
which should have been kept separate.  Unfortunately, the inertia of all
those programs running already will probably preclude us from re-defining
the process startup primitives.  An alternative solution to the problem
of poor performance during the fork() is to use a copy-on-write algorithm
which gradually duplicates the parent's address space as the parent or child
attempts to change values.  (Can you say real MMU? :-)

-- 
Russell Kent			Phone: +1 214 995 3501
Texas Instruments - MS 3635	Net mail:
P.O. Box 655012			...!{ihnp4,uiucdcs}!convex!smu!tifsie!kent	
Dallas, TX 75265		...!ut-sally!im4u!ti-csl!tifsie!kent