On May 16, 5:12pm, dm...@samersoff.net (Dmitry Samersoff) wrote:
-- Subject: Re: vfork instead of fork for fork+exec?
| On BSD vfork() stops parent process until child exited or call exec.
| It's not acceptable in multithreaded environment.
Yes, this could be a problem if the program does not run exec
immediately after vfork(), but in practice most programs run exec,
a couple of dups, and vfork because there is not much else you can
legally do without trashing the state of your parent.
| Also real performance difference between fork() and vfork() is not huge
| because all modern kernels use copy-on-write and copy only in-kernel
| page table, not pages it self.
This is not true, because the child process still needs to do a
lot of VM work to setup/copy the page table entries. The larger
the process is the bigger the penalty, and java processes at least
where I work are very large. 4.4BSD removed vfork on that assumption,
and then we did some performance testing on NetBSD and we ended up
putting it back, and making the shell use it for significant
Yes vfork is a weird syscall, annoying and difficult to use, but please
don't make performance claims without actually doing any tests.
I can try to dig up our performance numbers if you like.