lkml.org 
[lkml]   [1999]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Porting vfork()
    On Thu, Jan 07, 1999 at 02:07:51PM +1300, Chris Wedgwood wrote:
    > On Tue, Jan 05, 1999 at 03:46:11PM -0600, kernel@draper.net wrote:
    >
    > > As of late the "different" vfork() behavior in Linux is appearing
    > > as a porting problem more often than expected (by me).
    >
    > Specifically, what is breaking?
    >
    > Most applications I've seen that use vfork seem to work without any
    > changes here....
    >

    Agreed. Most are fine, however...

    In a proper vfork() implementation, the child shares its parent's address space
    (and usurps the parents thread of control) until a call to execve (or exit)
    is made. Note that the parent is suspended until the child calls execve
    or exit.

    Linux aliases vfork() to fork()... problematic in two areas:

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

    When the parent expects the child to alter the parent's memory (manipulate
    the file descriptor table, modify a global variable, or whatever) prior to
    the execve... a current address space porting problem arises.

    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.

    IMHO, both of these issues are the result of silly application coding.
    (Given that parent thread of control is usurped AND if access to parent
    memory is needed then the programmer should have done his/her work prior to
    the call to vfork() in the first place!).

    My intent in this thread was to gage the vfork() impact. It makes no sense
    to commit time developing a kernel solution if only a very few applications
    have such silly dependencies.

    Regards,
    Reed H. Petty
    rhp@draper.net

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