lkml.org 
[lkml]   [1999]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectA good reason to use vfork()
First, I want to acknowledge the very good point made by others that
_depending on_ the non-portable behavior of vfork() suspending the parent
is, is in general, a BAD THING. I'm *not* suggesting new code should
depend on this behavior if it can be avoided -- and it almost always can.

This is about something completely different.

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.

Scenario 1: In the case of a server that absolutely depends on a copy of
itself to handle a particular event without, for example, leaving some
critical data file (etc.) in an inconsistent state, the best behavior is to
simply have the "fork()" fail -- *particularly* with copy-on-write
semantics. Even if the child process *never* calls malloc() or requires
additional stack space, it could die in mid-expression by simply assigning
to an *existing* variable and triggering a copy of one page too many. The
child process (which may be in a critical section) is now itself in an
inconsistent state, and it may be far too late or far too difficult for the
parent to fix the problem. For that matter, fixing the problem might
require more additional VM than available. If fork() fails in this case,
the chances of the server being able to maintain consistent state (at least
dieing gracefully) are much improved. At least some (most?) commercial
UNIXen behave this way (by default, at least) for precisely this reason.

Scenario 2: Rather than a self-spawning server, a critical application has
consumed an enormous amount of VM over an enormous amount of time in
calculating a result -- far more than half of all VM. The user scans the
results in the UI and decides to save or print the results. Either action
requires pumping the data through an arbitrary external filter program that
requires _very little_ VM. So now the application needs to call some
variant of fork(), then almost immediately, exec(). In this case, the
amount of VM actually required by the child has almost nothing to do with
the VM required by the parent. If the "fork()" fails in this case, there
may be no work-around for the user aside from more VM. *This* is where
calling vfork() is much more likely to produce the desired result than
fork() on some platforms -- and no worse than calling plain old fork().

Example uses: system(3), popen(3), perl(1).

Best regards,
Chuck

-
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.196 / U:0.896 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site