Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!zephyr.ens.tek.com!orca.wv.tek.com!frip!andrew
From: andrew@frip.WV.TEK.COM (Andrew Klossner)
Newsgroups: comp.arch
Subject: Re: Why fork? (long, was Re: IBM PC prehistory)
Message-ID: <5875@orca.wv.tek.com>
Date: 16 Jan 90 21:54:57 GMT
References: <610@ssp11.idca.tds.philips.nl> <952@dms.UUCP>
Sender: andrew@orca.wv.tek.com
Reply-To: andrew@frip.wv.tek.com
Organization: Tektronix, Wilsonville, Oregon
Lines: 33

Yep, most uses of fork() are quickly followed by exec().  But the
exec() doesn't happen within a couple of instructions.  Typically this
sort of thing happens:

	fork()
	child does:
		close files that child won't need;
		open (or otherwise establish) standard input, output,
			and error files;
		exec(argc, argv, environment_p);
		print_error("exec failure"); exit();

Wrapping up all the interesting child manipulation of files into
options to one huge spawn() call would be cumbersome.

Berkeley 4.1BSD Unix addressed the problem by inventing the vfork()
syscall, which creates a new child thread but runs it in the parent's
environment.  This eliminates the need to clone writable memory, or to
set up a new set of page table entries with "copy-on-write" set.  The
parent thread is suspended until the exec(), and any change that the
child makes to memory before the exec() are seen by the parent.

vfork() is marked for extinction in a future BSD release.  We
extinguished it on our BSD-derived 68k workstation (for reasons that
were sound at the time).  Yes, you have to build a duplicate set of
page tables in order to implement copy-on-write, but for processes that
aren't huge, this isn't a large part of fork() handling.  The kernel
has to do a lot of other work besides just building the PTEs.  For huge
processes, though, we've observed that PTE creation time dominates
fork() time.

  -=- Andrew Klossner   (uunet!tektronix!frip.WV.TEK!andrew)    [UUCP]
                        (andrew%frip.wv.tek.com@relay.cs.net)   [ARPA]