Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!sunybcs!boulder!hao!oddjob!mimsy!chris
From: chris@mimsy.UUCP
Newsgroups: comp.arch,comp.unix.wizards
Subject: Re: UNIX fork
Message-ID: <8904@mimsy.UUCP>
Date: Sat, 3-Oct-87 18:31:32 EDT
Article-I.D.: mimsy.8904
Posted: Sat Oct  3 18:31:32 1987
Date-Received: Sun, 4-Oct-87 06:57:07 EDT
References: <125@quick.COM> <246@tifsie.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 30
Xref: utgpu comp.arch:2322 comp.unix.wizards:4321

In some article (the quoting was improper, and I have forgotten who)
someone writes:
>>... That's why Berkeley has vfork().  A vfork call
>>"borrows" the parent's memory instead of copying it.

In article <246@tifsie.UUCP> kent@tifsie.UUCP (Russell Kent) replies:
>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.

Not so.  Were this the case, vfork() would be nearly useless.
Vfork borrows the parent's *memory*; this does not include its
kernel space information, such as file descriptors.  (`FILE *'s
are indeed borrowed; the child is simply not supposed to muck about
with them.)

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

The standard objection to this is that the parent is likely
immediately to change some values, and that it may be cheaper to
duplicate the entire process once than to do it piecemeal.  A
standard solution is for the child to `borrow' the parent's memory
(read only) until it exec()s or some short time has passed, after
which the parent is allowed to continue regardless.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris