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