Messages in this thread | | | Date | Fri, 8 Jan 1999 13:19:20 -0500 (EST) | From | Kenneth Albanowski <> | Subject | Re: Porting vfork() |
| |
On Fri, 8 Jan 1999, Linus Torvalds wrote:
> > > On Fri, 8 Jan 1999, Kenneth Albanowski wrote: > > > > 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. > > The semaphore has the problem that you can deadlock and create unkillable > processes. Not nice.
I don't mean a semaphore, then. I mean something where the winner goes ahead with the vfork(), and the loser immediately fails the syscall with EINVAL.
> A semaphore with "down_interruptible()" would be acceptable, I guess.
The recursive vfork() is almost certainly going to dead-lock in any case, so it just needs to fail gracefully and be done with it.
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.
Hmm... I do wonder about what happens to signals while vfork() is blocking the parent, though. Ick. The parent invoking signal handlers isn't much better then the child invoking signal handlers. One longjmp(), and everything gets confused. Temporarily block all signals to the parent but SIGKILL? Perhaps the only solution. And how does the child cleanly release the wait_queue in its parent if its parent may have been killed in the meantime?
Yuck, this is messy, I like the mm_struct approach better. But that won't let a multi-threaded app easily fork from any thread, and I really ought to get that working.
(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.)
-- 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/
| |