Re: Porting vfork()
Alain Williams (addw@phcomp.co.uk)
Sun, 10 Jan 1999 23:12:04 +0000
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.
--
Alain Williams
-
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/