[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.020 / U:13.756 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site