Messages in this thread | | | Date | Sat, 9 Jan 1999 07:54:27 +0000 | From | Jamie Lokier <> | Subject | Re: Porting vfork() |
| |
On Fri, Jan 08, 1999 at 11:05:51PM -0300, Horst von Brand wrote: > Jamie Lokier <lkd@tantalophile.demon.co.uk> said: > > That said, now that multiple tasks can share an MMU context, it would > > probably be quite easy to support vfork() semantics. > > All I've ever read on the subject says vfork(2) was an unclean > implementation of fork(2) semantics (sort of) for efficiency sake. It makes > no sense to work to replicate accidental, totally non-wanted and even in > the original explicitly marked as not-to-be-relied-on semantics. Easy to do > or not.
Depends on your point of view.
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.
-- Jamie
- 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/
| |