lkml.org 
[lkml]   [1999]   [Jul]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: kernel thread support - LWP's
    From
    Date
    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.

    >
    > ---
    >
    > If there were a way to specify - ideally at clone time - that any task in
    > some group (process group would be fine with me) can wait for this child,
    > then the above gunk could be reduced to clone() plus the work of setting up
    > the child's stack (the mmaps) and user-level context (data for
    > pthread_setspecific, per-thread errno, etc.) And that would get you a hell
    > of a lot closer to 3usec thread create times. If you had a

    This sounds reasonable. CLONE_WAIT ? Shouldn't be that hard to implement.


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

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

    Other things I would like to add to the kernel for better linuxthreads:

    - cmpxchg kernel emulation for 386.
    Currently linuxthreads do 2 function calls, a switch (to check lock types) and
    a if (to check if the cpu has cmpxchg) for the uncongested case. If it was
    guaranteed that cmpxchg works on all cpus that could be optimized heavily by
    inlining the cmpxchg and only dropping to the functions if the lock is congested.
    This would make uncongested locks very cheap. It would slow down the 386er a
    bit, but these are hopeless for threads anyways
    because of the user access races.
    required kernel changes: straight forward emulation in the kernel SIGILL handler,
    code size is directly proportional to the number of weird addressing modes
    emulated (and kernels compiled for >386 won't see it anyways)

    - a vm id for ps support:
    add a pid field to the "mm_struct" that is shared by CLONE_VM; initialise this
    field when the mm_struct is first created and don't change it for clones; then
    make it available via proc/<pid>/something. This would allow ps to find all
    "threads", and would allow gdb to attach to already running "thread sets"
    required kernel changes are about 5-10 lines.

    - support to write register sets for all threads that use the vm into the core
    dump.

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