Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!sun-barr!ccut!titcca!cc.titech.ac.jp!necom830!mohta
From: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
Newsgroups: comp.arch
Subject: Re: fork, spawn, vfork: an overview
Message-ID: <5988@titcce.cc.titech.ac.jp>
Date: 6 Aug 90 16:22:04 GMT
References: <25904@mimsy.umd.edu> <12382@encore.Encore.COM>
Sender: news@cc.titech.ac.jp
Organization: Tokyo Institute of Technology
Lines: 38

In article <12382@encore.Encore.COM> jkenton@pinocchio.encore.com
	(Jeff Kenton) writes:

>Beauty is only skin deep, but ugly goes right to the bone.

True.

The problem here is that the semantics of fork-exec is really ugly,
because it is virtual memory ineffecient.

First, by simple implementation, it requires unnecessary copying
of virtual memory.

By COW workaround, copying is not necessary. But the fundamental ineffeciency
on virtual memory is still there. So, a large process can't fork.

By not-pre-allocating-swap-space workaround, a large process can now fork.
But the fundamental ineffeciency on virtual memory is only hidden from the
sight and still exists. So, now, there is possibility of deadlock.

So, the ugliness of virtual memory ineffeciency is really goes
right to the bone.

The solution is to get rid of the ugly virtual memory ineffeciency.

Thus
	vfork - spawn new process in a virtual memory efficient way

To appreciate beauty of vfork, you should first think of general
purpose segment sharing mechanism. Then, by using the mechanism,
you can construct a virtual memory effecient way to spawn a
process.

BTW, for the complete beauty, vfork should have been designed so
that changes to registers in a child context are also reflected
to the parent process. That is important for a highly optimized compiler.

						Masataka Ohta