Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker!spdcc!esegue!johnl
From: johnl@esegue.segue.boston.ma.us (John R. Levine)
Newsgroups: comp.arch
Subject: Re: fork()
Message-ID: <1990Feb28.174312.7640@esegue.segue.boston.ma.us>
Date: 28 Feb 90 17:43:12 GMT
References: <37873@cornell.UUCP>
Reply-To: johnl@esegue.segue.boston.ma.us (John R. Levine)
Distribution: comp
Organization: Segue Software, Cambridge MA
Lines: 22

In article <37873@cornell.UUCP> huff@cs.cornell.edu (Richard Huff) writes:
>We could eliminate fork() and
>exec() in favor of create() and activate(), where:
> ...
>Here's the key point: between the create() and the activate(), the
>parent process can do all of those wonderful things that others have
>moaned and groaned need to be done between a fork() and an exec().  We
>need only have separate kernel calls that allow a parent process to
>manipulate the environment of its suspended children.

Uh huh.  We get rid of fork() and add a hundred new remote context
manipulation calls, hoping that we remember every single thing that a process
would want to do to itself, and trying to remind ourselves that every time in
the future we add some new item to the process context, we have to provide a
way not just for a process to change its own context, but also a different way
to change the context of other processes, and then invent a whole new set of
protection rules about what processes are allowed to change what context bits
in what other processes.  This is progress?  No thanks.
-- 
John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650
johnl@esegue.segue.boston.ma.us, {ima|lotus|spdcc}!esegue!johnl
"Now, we are all jelly doughnuts."