Consider:
vfork();
execl(GetExecutableName(),...);
Who knows how many pages 'GetExecutableName' might alter?
If there is enough virtual memory to allow a vfork to succeed there is
enough to allow a fork to succeed. Overcommitting is either on or it's off.
DS
> 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/