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/