Re: Porting vfork()

Kenneth Albanowski (kjahds@kjahds.com)
Thu, 7 Jan 1999 15:25:30 -0500 (EST)


On Thu, 7 Jan 1999, Linus Torvalds wrote:

>
>
> On Thu, 7 Jan 1999, Kenneth Albanowski wrote:
> > >
> > > wake_up(&mm->sleep);
> > >
> > > at the top of the function.
> >
> > You'll also need a wake_up in kernel/exit.c.
>
> No, exit_mm will call mmput(), so that will do the wakeup as far as I can
> tell.

Ah, yes, I see. I'm still stuck at 2.0.x, so I'm not familiar with the new
arrangement, but that makes a lot more sense.

> > > if (child > 0) {
> > > while (current->mm->count > 1)
> > > sleep_on(current->mm->sleep);
> > > }
> > > return child;
> > > }
> >
> > Interesting. Did you have a particular reason to expect this loop to be
> > triggered?
>
> No, as I disabled the recursive thing anyway. With a recursive thing you
> need a while loop, but the above wouldn't work anyway (the "1" is no
> longer a one at all). So you could certainly change the 'while' into an
> 'if'.

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)

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