Messages in this thread | | | From | Chuck Phillips <> | Date | Tue, 2 Nov 1999 22:13:10 -0700 (MST) | Subject | RE: A good reason to use vfork() |
| |
David Schwartz writes: > I don't follow you. Are you saying that a kernel that would fail a fork > should allow a vfork to succeed?
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/
| |