🚀 go-pugleaf

In article <1990Feb28.174312.7640@esegue.segue.boston.ma.us> johnl@esegue.segue.boston.ma.us (John R. Levine) writes:
>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.

Mr Huff's scenario is approximately what I was used to doing before I
switched to working on Unix. I found it to be a bit more cumbersome to
use than fork(), but considerably more efficient and flexible. It lends
itself well to automation by means of a library of functions.

Terry

#include <disclaimer.std>