Messages in this thread | | | From | Jakub Jelinek <> | Subject | Re: Porting vfork() | Date | 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/
| |