[lkml]   [1999]   [Jul]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: kernel thread support - LWP's
On 16 Jul 1999 19:31:08 +0200, Andi Kleen wrote:
> (Zack Weinberg) writes:
>> There's another lovely detail: The "initial thread" (the one that was
>> executing before the first call to pthread_create) isn't a child of the
>> manager; it's the parent of. Per POSIX, the manager has to notice when the
>> initial thread goes away and kill all the others. That's why there is a
>> getppid in the above. The select times out every two seconds just so it can
>> check.
>Does it require that for kill -9 too?
>If no, it could be handled in a _exit hook in user space.

I'm not sure if kill -9 <threaded process> is supposed to hit just one
(random) thread in the process, all of them, or just the initial thread, in
the POSIX semantics. But assuming that the initial thread does get a
kill -9, yes, all the others are required to go away too.

>> CLONE_VM_WITH_NEW_STACK that created a new stack for the child (still
>> visible to both) then more overhead would go away, plus clone() wouldn't
>> need a special assembly stub that only works if you use CLONE_VM.
>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.

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


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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