lkml.org 
[lkml]   [1999]   [Jul]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: kernel thread support - LWP's
On Fri, Jul 16, 1999 at 03:12:37PM -0400, Zack Weinberg wrote:
> >Linus has very strong feelings against this, and i think he is right there.
> >Stack management should be done in user space. You would just move some stuff
> >that can be equally well done in user space into a giant system call.
>
> You're right about stack management being done in user space, but this
> forces the libc clone() stub to be coded in such a way that it can't be used
> without CLONE_VM. (Or you could write one that only works without it. You
> just can't have it both ways.) This is because clone() with CLONE_VM
> returns twice on the same stack, and will die horribly if allowed to do
> anything at the C level afterward. Like vfork, only worse.

I think that is reasonable, as long as that complexity is hidden in libc.

>
> >> It would also be handy to have a "disown" call which had the effect of
> >> immediately reparenting the target process to init. Currently "detached
> >> threads" have to be waited for too.
> >
> >This already exists. Do prctl(PR_SET_DEATHSIG, SOME_NEW_SIGNAL) in the child
> >and ignore that signal in the parent (at least it should work in theory,
> >I haven't tested it)
>
> I think if you do that then the zombie never gets reaped.

True, it needs SA_NOCLDWAIT too (which does not work ATM)

-Andi

--
This is like TV. I don't like TV.

-
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:53    [W:0.071 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site