[lkml]   [1999]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Porting vfork()
    > > 
    > > 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

    > 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

    > Kenneth Albanowski (, CIS: 70705,126)


    Perry Harrington Linux rules all OSes. APSoft ()
    email: Think Blue. /\

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