> > Oh, but if the wait queue is moved into the task_struct, the vfork()'d
> > child will already be providing a diffent queue, and it's no longer
> > recursive. I guess that solves the problem. It would only be an issue if
> > the parent could issue vfork() twice, which it can't.
>
> 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.
> 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.
> 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.
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.
> > (Again, for those who think this whole thing is silly: an implementation
> > of vfork() essentially identical to what Linus is describing is the only
> > fork() call available in uClinux. I care very much about having a decent
> > implementation. This could crop up again in other weird architectures, so
> > me might as well get it done once and for all.)
>
> 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.
-- Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
- 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/