Messages in this thread | | | Date | Fri, 8 Jan 1999 01:06:58 -0500 (EST) | From | Kenneth Albanowski <> | Subject | Re: Porting vfork() |
| |
On Thu, 7 Jan 1999, Perry Harrington wrote:
> I discussed this issue with Linus as well, and concluded that vforking > within a cloned process can be achieved via putting the sleep_on in the > task structure. I'm going to be working on this tonight and I'll see > what I can do.
I do think a sempahore would be appropriate to avoid the possibility of recursion. I can just see someone coverting the "double fork" trick into a "double vfork" trick, and really confusing things. At some point a list might make sense, but this is probably getting needlessly complex.
A proper implementation also needs to worry about signals interrupting the sleep, of course.
> I had one question that I think you could answer: vfork() does not > copy the signal handler of the parent, correct?
Actually, I can't speak to what vfork() does or doesn't so, at least to the degree that I've never used a system with traditional vfork(). I needed to craft my own vfork() specifically because uClinux is incapable of copying the stack between processes, which prevents a traditional fork() from operating properly.
As it happens, I used fork() as the implementation of my vfork(), so it should be retaining the DFL/IGN state of the signals, but not the assigned handlers. While I expect a traditional vfork() implementation would tend to share just about everything (on the assumption that that is the trivial implementation), I can also see that letting the vfork()'d child attempt to handle the parents signals would be an extremely Bad Thing.
In other words, I'd definitely leave off CLONE_SIGHAND. But the rest of the clone flags should be safe.
> > Come to think of it, though, one thread (of a bunch that are using the > > same mm) ought to be able to vfork(), even if more then one can't. Maybe > > add a mutex around the sleep (this doesn't involve recursion, just > > multithreading, so deadlock shouldn't be too much of an issue), or give up > > and move the sleep wait_queue into the task_struct. Might need another > > count to prevent recursion, though. > > > > Before anyone asks, yes, this is almost a real-world issue. If I had > > needed to speed up a uClinux httpd much more, it would have been > > multi-threaded, and it was already CGI capable... > > > > -- > > Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126) > > > > --Perry > > -- > Perry Harrington Linux rules all OSes. APSoft () > email: perry@apsoft.com Think Blue. /\ >
-- 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/
| |