Messages in this thread | | | Subject | Re: A good reason to use vfork() | Date | Tue, 02 Nov 1999 18:12:36 -0500 | From | "Brandon S. Allbery KF8NH" <> |
| |
In message <14366.58194.716987.702535@cdp.localnet>, Chuck Phillips writes: +----- | Imagine a single process that has managed to acquire more than half of all | available Virtual Memory, or in the more general case, creating a | *complete* copy of itself requires more VM than is available. Now it needs | to call some variant of fork(). What should happen? Well, that depends. +--->8
fork() marks non-shared pages copy-on-write, instead of copying them immediately; they won't take any additional VM unless they are written to. At most this should be one stack page and possibly one data page; otherwise, you've also violated the restrictions on vfork() so you will lose anyway (the child may succeed, but the parent's memory will be corrupted).
Basically, any situation which is a no-win for copy-on-write fork() will lose in a different way for vfork(), and neither one is likely to be easily recoverable. In fact, the vfork() version will probably lose worse because the kernel can't do *anything* about it: the corruption is entirely user-space. Whereas if vfork() will succeed, so will fork().
With respect to your examples: when the child exec()s, the copied pages are immediately reused. If they aren't available for the fork() to use, they aren't going to be available for the exec() either, so you lose regardless. The only difference is that the failure happens at fork() time instead of at exec() time --- and vfork() assumes the exec() will succeed, so the parent's stack will very probably be trashed by the vfork()ed child in the aftermath of the failed exec(). (Not to mention trashing due to anything that happens that can't be blocked by _exit(), unless the failing child's response is to SIGKILL itself --- if it sends a signal for which a handler exists, again the parent will be trashed.)
-- brandon s. allbery os/2,linux,solaris,perl allbery@kf8nh.apk.net system administrator kthkrb,heimdal,gnome,rt allbery@ece.cmu.edu carnegie mellon / electrical and computer engineering kf8nh We are Linux. Resistance is an indication that you missed the point.
- 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/
| |