Messages in this thread | | | Subject | Re: kernel thread support - LWP's | Date | Fri, 16 Jul 1999 15:12:37 -0400 | From | Zack Weinberg <> |
| |
On 16 Jul 1999 19:31:08 +0200, Andi Kleen wrote: >zack@rabi.columbia.edu (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.
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/
| |