Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!mintaka!snorkelwacker!spdcc!esegue!johnl From: johnl@esegue.segue.boston.ma.us (John R. Levine) Newsgroups: comp.arch Subject: Re: Spawn is impossible to define (was Re: vfork) Summary: Really. Message-ID: <1990Jul24.194313.3258@esegue.segue.boston.ma.us> Date: 24 Jul 90 19:43:13 GMT References: <920@dgis.dtic.dla.mil> <5830@titcce.cc.titech.ac.jp> <5931@titcce.cc.titech.ac.jp> Reply-To: johnl@esegue.segue.boston.ma.us (John R. Levine) Organization: Segue Software, Cambridge MA Lines: 45 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. If the parent enables quits around the spawn() so that the enabled status is inherited by the child, you run the risk that the user will hit quit at an inconvenient time and will blow the parent away, too. To fix this particular nit either you have to pass a signal status vector to your spawn() call or else crud up the signal system with a state that means accept-if-inherited-in-subprocess-but-not-here. Ugh. When I first thought about this problem, I also thought that it should be possible to come up with a spawn call that would obviate fork/exec. Now I'm convinced that it can't be done. 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. It seems to me that if you want to add spawn, you have a small set of options: -- 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. -- Redo every call that affects process context so that it takes as an extra argument the PID of the process to change, defaulting to one's own process. Then spawn needs only one option, to freeze the child until the parent releases it after doing all the context changing. Details of what process is allowed to change the context of what other processes are left for the reader, but are clearly a major can of worms if you have any pretense of security (what if the child is set-uid to root?) -- Implement a limited spawn() while leaving fork/exec for the hard cases, but use spawn for the common cases to make things fast. The problem here is that the most common place for fork/exec is from a shell or shell procedure, and shells both tend to be pretty small, and to do considerable munging of file descriptors and signals after the fork. Thus, the most common case also happens to be one of the cheapest now and to be fairly obnoxious to handle with spawn(). -- Give up and stick with fork and exec. That's my choice. -- 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 Marlon Brando and Doris Day were born on the same day.