Messages in this thread | | | From | Perry Harrington <> | Subject | Re: Porting vfork() | Date | Fri, 8 Jan 1999 11:46:39 -0800 (PST) |
| |
> > > > 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/
| |