Messages in this thread | | | Subject | Re: Porting vfork() | Date | Mon, 11 Jan 1999 11:28:04 -0300 | From | Horst von Brand <> |
| |
Tim Smith <tzs@tzs.net> said: > On Sun, 10 Jan 1999, Torbjorn Lindgren wrote: > > The requirements are basically (paraphrased): > > * Don't modify any data other than a variable of type pid_t used to store > > the return value from vfork() > > * Don't return from the function in which vfork() was called. > > * Don't call any functions before successfully calling _exit(),or one of > > the exec family of functions.
> That last requirement seems overly stringent. I'd expect the child to be > able to (and need to) call open, close, dup, fcntl, etc., to deal with > IO redirection before calling exec.
Then you can't use vfork(2), you must use fork(2).
All this trouble to shave off a fraction of a percent on a libc build. I just don't get it.
[The BSD folks claim "a few seconds less in a libc build", let's make that 5 seconds out of 30 minutes (this should be generous). That makes a full 0.27%.] -- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |