>
>
> 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/