> Jason Thorpe sez:
> /*
>  * Hi folks,
>  * 
>  * Well, with NetBSD 1.3 almost out the door (the announcement should be
>  * any time now..), it's time to start thinking about running -current
>  again * (well, for some of us :-)
>  * 
>  * ...  This new implementation will have the
>  * original 3BSD vfork semantics: a completely shared address space as well
>  * as parent blocks for child exit (contrast that to the current NetBSD
>  vfork * that came from 4.4BSD, which simply blocks the parent).
>  * 
>  * Orignally, vfork was implemented because the address space was copied at
>  * fork time.  This was a time consuming process, and a real waste if the
>  * program were to immediately exec (which would then unmap the address
>  space * so painstakenly copied just moments ago).  When copy-on-write was
>  added * to BSD (when it got the Mach VM system)...
> 
	Question:

	Is the new vfork() really the right answer to the problem, i.e.
	would we be better off finding the reasons why the VM/fork() is
	so damn slow and fixing that rather than just rehashing vfork()?

	vfork() has always struck me as having way too many "gotcha's" to
	remember, getting VM/fork() speeded up in general would seem a
	better long term solution.

	Just wondering,

		-Rob