lkml.org 
[lkml]   [1999]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Porting vfork()

Chris Wedgwood writes:
> On Wed, Jan 06, 1999 at 08:28:55PM -0600, kernel@draper.net 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.

http://www.netbsd.org/Documentation/kernel/vfork.html

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.038 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site