Re: Porting vfork()
Jakub Jelinek (jj@sunsite.ms.mff.cuni.cz)
Mon, 11 Jan 1999 10:54:04 +0100 (CET)
>
> On Sat, Jan 09, 1999 at 07:54:27AM +0000, Jamie Lokier wrote:
> > Now that we have the mechanism for clone(2), we can give Linux vfork(2)
> > can-be-relied-upon semantics -- we're able to guarantee that the memory
> > spaces are shared until the next exec(2). Assuming you're using a
> > recent enough kernel, that is. It would make most sense implemented as
> > another flag to clone(2), so it fails with an older kernel.
> >
> > vfork would probably be _slightly_ faster, because there would be no
> > need to copy the VMA list and one TLB flush could be skipped assuming
> > one context switch before the exec(2).
> >
> > I don't actually recommend this, however. vfork == fork seems cleanest
> > to me.
>
> If we bother with vfork() at all it is more important that it is
> 'correct' (ie things that use it don't need to be hacked to work under
> Linux) than that it is super fast. Not many things use it so speed is
> not the *important* (or do I mean visible) issue.
This is plain wrong. Really many things use it. Just scan all your binaries
for vfork, you'll be surprised. The thing is that not many things rely on
whether it works as documented vfork, or whether it is the same as fork.
But, if you read the NetBSD paper, you'll find out vfork has several
advantages, which are worth of considering.
Cheers,
Jakub
___________________________________________________________________
Jakub Jelinek | jj@sunsite.mff.cuni.cz | http://sunsite.mff.cuni.cz
Administrator of SunSITE Czech Republic, MFF, Charles University
___________________________________________________________________
UltraLinux | http://ultra.linux.cz/ | http://ultra.penguin.cz/
Linux version 2.2.0-pre6 on a sparc64 machine (3958.37 BogoMips)
___________________________________________________________________
-
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/