lkml.org 
[lkml]   [1999]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: A good reason to use vfork()
Date
From
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/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.052 / U:0.636 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site