Messages in this thread | | | From | (Matthias Urlichs) | Subject | Re: Porting vfork() | Date | 8 Jan 1999 10:36:42 +0100 |
| |
kernel@draper.net writes: > > (Given that parent thread of control is usurped AND if access to parent > memory is needed then the programmer should have done his/her work prior to > the call to vfork() in the first place!). > The only reason I would want to have vfork() is for reliably determine whether a fork/exec sequence died because of a failed exec().
With vfork, you just do execve(...) shared_errno = errno; _exit(); in the child. Without vfork you'll have to use a pipe, set the close-on-exec flag, and write the errno down the pipe (with the understanding that you get EOF when the exec succeeded).
We can do the same sort of thing as vfork() with clone() and shared VM, of course, but both non-vfork solutions have race problems if you try and implement them as "straight" vfork replacements.
These days, of course, enough Unixes have a nontraditional (or just plain missing) vfork() that I fail to see the point of why we'd need one, all of a sudden. ;-)
-- Matthias Urlichs | noris network GmbH | smurf@noris.de | ICQ: 20193661 The quote was selected randomly. Really. | http://www.noris.de/~smurf/ -- I prefer the most unjust peace to the most righteous war. --Cicero Even peace may be purchased at too high a price. --Poor Richard
- 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/
| |