Path: utzoo!utgpu!watserv1!watdragon!lion!ccplumb
From: ccplumb@lion.waterloo.edu (Colin Plumb)
Newsgroups: comp.arch
Subject: Re: Why fork? (long, was Re: IBM PC prehistory)
Message-ID: <19951@watdragon.waterloo.edu>
Date: 18 Jan 90 22:56:57 GMT
References: <610@ssp11.idca.tds.philips.nl> <952@dms.UUCP> <7446@cbnewsh.ATT.COM>
Sender: daemon@watdragon.waterloo.edu
Reply-To: ccplumb@lion.waterloo.edu (Colin Plumb)
Organization: U. of Waterloo, Ontario
Lines: 21

The other way to avoid fork() is to recognise that the only thing that
survives the eventual exec() is kernel-maintained state, so a call
(which takes the place of fork()) to ask the kernel to create a new
process state, and an additional argument to all state-changing system
calls to specify which state (since now more than one can be associated
with a single thread of execution) to use will achieve the same
effect.  exec() is replaced by something which gives one of the states
(it doesn't really matter which) a different load image and starts it
executing.  This is kind of like vfork() except it doesn't even try to
fake two threads.

The essential idea stolen from Unix is that the system calls uised to
manipulate the child's environment are the same ones used to manipulate the
parent's.

P.S. It actually may be useful to have two states maintained for a long time.
It gives you two ownerships, so you can avoid the effective uid kludge to a
large degree, and more signal bits if you use them for IPC, etc.  The
only problem is, which process gets signalled for bus error, etc.?
-- 
	-Colin