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