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 Fri, 8 Jan 1999, Linus Torvalds wrote:

>
>
> On Fri, 8 Jan 1999, Perry Harrington wrote:
> > >
> > > 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?
>
> No need to. If you use sleep_on(), the parent won't be getting any signals
> anyway (only sleep_on_interruptible() cares about signals).

Of course, but is that a good thing? The parent will be unkillable until
the child does something. Assuming the child wants to deny service in this
manner, you can always kill the parent by killing the child first, but
will process killers (human or automated) grok this? Is there anything
else in common use that causes this sort of behaviour?

It's a little more work, but it might be nice to make the parent listen to
SIGKILL.

--
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.132 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site