Re: Porting vfork()

Perry Harrington (pedward@sun4.apsoft.com)
Fri, 8 Jan 1999 11:10:49 -0800 (PST)

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

Yep, separate wait queue for each instance, child notifies parent, everything
is happy.

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

That's a good question, do you want to temporarily block signals to the parent?

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

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.

>
> (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.

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