lkml.org 
[lkml]   [1999]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Porting vfork()
    Date
    > > 
    > > Yep, separate wait queue for each instance, child notifies parent, everything
    > > is happy.
    >
    > Make sure that the parent hasn't gone away in the meanwhile.

    When it is an issue (before exec/exit) it's still considered a cloned thread and
    the parent can't go away without the child going away too.

    >
    > > That's a good question, do you want to temporarily block signals to the parent?
    >
    > I'm not sure, and I'm not sure what traditional behaviour is for this.
    > Letting the parent execute a signal handler is pretty clearly wrong, so I
    > guess signals have to be blocked for the duration. What about SIGKILL? I
    > guess leave it unblocked, otherwise we could have an unkillable parent.
    > That means the parent could go away while the child is still running, so
    > make sure the child won't die if this happens.

    If I read the code right, see above, the parent can't go away while the child is
    dependent on it because the mm structure is shared beteen them.

    >
    > > The patch that I sent out (it's gonna hit the list sometime) bypasses the
    > > obvious problems of sharing VMs, by simply recognizing that in an MT app,
    > > your VM area WILL be modified, irregardless. For ST apps, you just have
    > > the parent go to sleep.
    >
    > Sorry, I didn't follow that. My assumption is that MT will work
    > identically to ST: the thread that invokes vfork() will go to sleep until
    > its child execs or exits. No other special behaviour is required. No
    > threads other then the one that vfork()'d will be affected.

    Correct, I'm just ignore the fact that the VM will change underneath the thread's
    child, it's immaterial because it's a threading issue, hence it's an app programmer
    issue.

    >
    > This behaviour seems to be required, due to the meaning of vfork(): the
    > parent and child share the stack, so they cannot both execute at the same
    > time (hence the wait_queue). Separate threads do not share the stack
    > (never mind that they share everything else), so each thread can use
    > vfork() independantly and safely.

    Since a vforked child is the same as a cloned thread, the stack should get cloned
    too, I think.

    >
    > >
    > > Well, I think it'll happen, my patch it out (I have a new rev in my tree which
    > > adds the syscall to unistd and fixes the p_pptr thing to p_opptr).
    > >
    > > I'm doing this because I'd like to see someone use the new vfork to write a better
    > > FTP server for Linux, not to mention that Apache could benefit CGI wise.
    >
    > Actually I'd be surprised if this vfork() would gain you anything on a
    > normal system: I don't see how it's particularly better then clone(). As I
    > said, I'm concerned with systems where fork() isn't feasible.

    It's the same as clone, it just blocks the parent. It's this semantic which makes
    it better; when the parent wakes up, it can do the wait on the child and wake up in
    the same context, avoiding a superfluous context switch, because the data is immediately
    available.

    >
    > Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
    >

    --Perry

    --
    Perry Harrington Linux rules all OSes. APSoft ()
    email: perry@apsoft.com Think Blue. /\

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