Subject: Re: new vfork(2) implementation
To: Computo Ergo Checksum <email@example.com>
From: Rob Healey <firstname.lastname@example.org>
Date: 01/06/1998 17:39:41
> 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)...
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.