Path: utzoo!attcan!uunet!tank!ux1.cso.uiuc.edu!uwm.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!ames!amdahl!terry From: terry@uts.amdahl.com (Lewis T. Flynn) Newsgroups: comp.arch Subject: Re: fork() Message-ID: <33e502oG8d0e01@amdahl.uts.amdahl.com> Date: 1 Mar 90 18:57:46 GMT References: <37873@cornell.UUCP> <1990Feb28.174312.7640@esegue.segue.boston.ma.us> Reply-To: terry@amdahl.uts.amdahl.com (Lewis T. Flynn) Distribution: comp Organization: Amdahl Corporation, Sunnyvale CA Lines: 28 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