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

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


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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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