lkml.org 
[lkml]   [1999]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Porting vfork()
Date
  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/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.124 / U:0.228 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site