Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!texbell!ficc!peter From: peter@ficc.ferranti.com (Peter da Silva) Newsgroups: comp.arch Subject: Re: Spawn is impossible to define (was Re: vfork) Message-ID: <=VW4JSA@xds13.ferranti.com> Date: 25 Jul 90 15:56:30 GMT References: <920@dgis.dtic.dla.mil> <5830@titcce.cc.titech.ac.jp> <5931@titcce.cc.titech.ac.jp> <1990Jul24.194313.3258@esegue.segue.boston.ma.us> Reply-To: peter@ficc.ferranti.com (Peter da Silva) Organization: Xenix Support, FICC Lines: 39 In article <1990Jul24.194313.3258@esegue.segue.boston.ma.us> johnl@esegue.segue.boston.ma.us (John R. Levine) writes: > In article peter@ficc.ferranti.com (peter da silva) writes: > >Signals can be reliably saved and restored, so they can continue to be > >inherited across spawn as they are now inherited across fork and exec. > Nope. Assume that the parent is ignoring quits, while the child accepts > them, as is typically the case when running something from a top-level shell. Well that case can be dealt with (parent catches and discards interrupts around the spawn call), but the reverse case creates a race condition. This is not good, but it's also true that UNIX signals are *full* of such race conditions (hit ^C fast enough and you can blow away the shell). What is needed is a "defer signals" state, along with "default, catch, and ignore". This would solve this race condition, and also the one where the signal handler gets interrupted before resetting the signal. > Enumerating all of the bits of the > user-visible context of a process is extremely hard, and of course every time > you add a new system call or feature, you porentially add more context. But you have to do this anyway to allow for proper use of fork/exec. Better to make *any* change in process context reversible, then set things up, spawn, and reset. Currently the only non-reversible inherited changes are open files and current directory. And, I guess, chroot(). > -- Have spawn point to a piece of setup code in the parent process that is > executed in the child process' context to set stuff up. This is what vfork > is supposed to do. And I agree that vfork is a good idea, besides being more convenient than spawn. I just don't see that spawn is really any more complex than, say, select(). > -- Give up and stick with fork and exec. That's my choice. You forgot: -- Make any change in the process context reversible. Which is a damned useful capability anyway. -- Peter da Silva. `-_-' +1 713 274 5180. 'U`