lkml.org 
[lkml]   [1999]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.492 / U:0.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site