stevens@inuxa.UUCP (11/01/83)
How does the (4.n BSD?) vfork() system call differ from the standard vanilla UN*X fork() system call (in terms of what it does to the kernel's data structures)? -- Scott Stevens -- AT&T Consumer Products Laboratories -- Indianapolis, Indiana -- UUCP: inuxa!stevens
chris@umcp-cs.UUCP (11/04/83)
Vfork() is intended to be a more efficient version of fork(),
especially for large programs. It is mainly useful for programs
wishing to exec() some other program. The idea behind vfork() is
to not actually copy all the pages of the program, when it isn't
going to use most of them anyway.
4.1 behavior:
Like fork(), vfork() produces a copy of a process. Unlike
fork(), it doesn't actually copy the process. Instead it
fiddles with kernel data structures a bit, copies the page
tables (memory allocation list) for the process to the new
process, and suspends the "parent" (who has, at the moment,
no memory, since it's all given to the "child"). The child
gets to run until it exit()s or exec()s something else.
Then, instead of releasing the memory/page tables/etc, the
kernel gives everything back to the parent and lets it
continue.
This "cheating" has the interesting side effect that the
code:
main () {
int i = 0;
if (vfork() == 0) /* child */
exit (i = 10);
printf ("i = %d\n", i);
}
prints "10". The child can modify the parent! However, this
is not useful for IPC since the parent is held suspended until
the child exit()s or exec()s. Also, this behavior is considered
wrong, and will change (has changed?) in future releases of
Berkeley Unix. Oh yeah, if "i" were a "register int" you'd
get 0 (howzat for consistency?).
4.2: (maybe, maybe not yet, ``definitely'' in 4.3)
The vfork() system call will be (has been?) changed to allow
both processes to run simultaneously, sharing memory resources
as long as the child does not attempt to write to the shared
memory. If the child does write to the shared memory, the
write is trapped and the memory is copied to a new page (or,
if necessary, depending on hardware, maybe the entire process
is copied) and the child shares one less page (or no pages).
This will actually be done to the fork() system call as the
behavior of fork() and vfork() will then be identical. The
new implementation is merely much more efficient (on paged
systems anyway).
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris.umcp-cs@CSNet-Relaydbj.rice%rand-relay@sri-unix.UUCP (11/07/83)
From: Dave Johnson <dbj.rice@rand-relay>
Like it says in the manual under BUGS in VFORK(2):
"This call is peculiar..."
Dave Johnson
Dept. of Math Science
Rice University
dbj.rice@Rand-Relayron%brl-vgr@sri-unix.UUCP (11/14/83)
From: Ron Natalie <ron@brl-vgr> National has done the "as needed" image copying in the fork system call in their 16032 unix. I think they do it for all forks which is not really a bad idea since most processes die or exec something shortly after being forked. -Ron