1999-01-08 19:25:56

by Albert D. Cahalan

[permalink] [raw]
Subject: Re: Porting vfork()

Chris Wedgwood writes:
> On Wed, Jan 06, 1999 at 08:28:55PM -0600, [email protected] wrote:

>> 2) When the parent can no longer assume (and requires) that the
>> child will be dispatched and execve prior to the parent
>> receiving control back from vfork()... a subtle race condition
>> porting problem arises.
> I can't think of an easy way to make this work...

Linus posted a basic roadmap. Without this, the shared VM is insane.

>> My intent in this thread was to gage the vfork() impact.
> We've go this far without it -- and it is a bit of a hack. I don't
> see why we should need to add it now. We should be able to fix a
> small handful of applications, and almost any OS can use fork()
> without too much penality as most implement COW.

NetBSD has a "Why implement traditional vfork()" page that explains
why they reimplemented vfork(). It seems vfork() is still good.