Messages in this thread | | | Date | Thu, 7 Jan 1999 15:40:41 +1300 | From | Chris Wedgwood <> | Subject | Re: 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/
| |