On Thu, 9 Apr 1998, Jason Thorpe wrote:

> 
> So, vfork(2) was introduced in 3.0BSD because at that time, there was no
> COW.  At fork time, the address space had to be copied.  This was determined
> to be a waste in the case where a program, such as the shell, would fork,
> and immediately exec a new program.
> 
> Basically, vfork(2) was used in lieu of a Better Solution, because that
> Better Solution was a bit off in the distance.
> 


> 
> So, we figured that re-enabling the old vfork(2) semantics would be
> a win.  Sure, it's a speed hack, but it's a speed hack that's been around
> for a fairly long time, and, if one knows the constraints of the interface,
> and how to use it correctly, it can be quite effective.
> 


Would a better long term option be to implement a forkexec() atomic
system call which someone else mentioned ? I'm not against a well
documented vfork. I just wondered what people thought of the atomic
fork and exec system call.

If we are to have vfork there should some comments about its problems
and maybe a note in the man pages BUGS section suggesting the
implmentation of forkexec().

--Sean