In some cases, yes.
> Even when it has no idea how much
> additional memory the process that completes the 'vfork' might need?
>
> Consider:
>
> vfork();
> execl(GetExecutableName(),...);
>
> Who knows how many pages 'GetExecutableName' might alter?
Absolutely correct. For this and other reasons, doing a lot of work
between vfork() and execve() (et al) is generally a BAD IDEA.
It would be better to write something like:
char *exeFile= GetExecutableName();
if (!vfork()) {
execl(exeFile, ...);
}
As soon as any of the execve(2) family succeeds, the child is no longer
sharing memory with the parent and altering pages is no longer an issue.
> If there is enough virtual memory to allow a vfork to succeed there is
> enough to allow a fork to succeed.
True, but this isn't always desirable.
> Overcommitting is either on or it's off.
Right. For several UNIXen, vfork() == overcommit, fork() == no-overcommit.
Each behavior is useful in the right situation. Both situations may arise
in the same executable, e.g., a forking server that prints using relatively
small external filters like ghostscript. Having both overcommit and
no-overcommit behaviors available simultaneously is very useful -- as
opposed to a global switch applied to everything.
I'm not about to argue that vfork()/fork() is the best way to accomplish
this. I'm only pointing out that this is *one* way, that it already
happens to work on several UNIXen, and that it is a natural consequence of
BSD's classic vfork() behavior (no page copies ever) combined with a
copy-on-write fork().
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/