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    [W:0.021 / U:31.632 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site