Messages in this thread | | | From | Chuck Phillips <> | Date | Tue, 2 Nov 1999 06:12:50 -0700 (MST) | Subject | A 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/
| |