lkml.org 
[lkml]   [1999]   [Jan]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Porting vfork()
On Wed, Jan 06, 1999 at 08:28:55PM -0600, kernel@draper.net wrote:

> 1) The child receives a new address space. Memory changes made by the
> vfork() child are not visible to the parent.

clone(...,CLONE_VM,...)

could in theory do this

> 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...

> IMHO, both of these issues are the result of silly application
> coding.

It's arguable either way...

> 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.

> It makes no sense to commit time developing a kernel solution if
> only a very few applications have such silly dependencies.

Indeed

-
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    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site