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