Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!samsung!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!wuarchive!texbell!ficc!peter From: peter@ficc.ferranti.com (Peter da Silva) Newsgroups: comp.arch Subject: Re: fork, spawn, vfork: an overview Message-ID: Date: 6 Aug 90 16:31:29 GMT References: <920@dgis.dtic.dla.mil> <5830@titcce.cc.titech.ac.jp> <1990Jul24.194313.3258@esegue.segue.boston.ma.us> <25904@mimsy.umd.edu> Reply-To: peter@ficc.ferranti.com (Peter da Silva) Organization: Xenix Support, FICC Lines: 15 I agree that vfork is a better mechanism. It also has one further advantage: - It can be implemented on machines with no MMU. This is what makes this such a frustrating subject. I'm not attacking fork() and vfork(). I think they're the best pair of ideas since sliced bread. But I have to deal with real-time operating systems where fork() can't be implemented at all, and vfork() can't be implemented cheaply outside the kernel. I also believe that the changes needed to make spawn() usable without excessive complexity are valuable in their own right. Come now, wouldn't you rather save your current directory so you can chdir() back instead of having to burn cycles calling getcwd()? How about having the nicer semantics of sigset() universally available via signal()? -- Peter da Silva. `-_-' +1 713 274 5180. 'U`