[lkml]   [2000]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: SCO: "thread creation is about a thousand times faster than on native Linux"
    I think the behavior below ought to solve our thread problems.
    Complain now or forever shut your trap.

    Kernel usage of CLONE_PID changes to CLONE_KERNEL_SMP, which is only
    allowed for the kernel itself.

    CLONE_PID changes the way a "process" is seen by unrelated processes.
    Signals must be sent to the thread group leader. Signals sent to
    individual tasks get ESRCH, while those sent to the whole process
    get delivered to every task... but see below. There is a separate
    system call for sending signals to individual threads; this call
    may be severely restricted to protect setuid code.

    CLONE_SIGQUEUE lets selected signals be delivered in the standardized
    first-available-thread manner. By default, tasks have a NULL pointer
    for the shared signal queue. When CLONE_SIGQUEUE is first used, it
    generates a shared queue with POSIX behavior. The behavior may be
    changed to choose which signals should get the first-available-thread
    delivery, and the behavior is inherited when CLONE_SIGQUEUE is used again.

    The parent of a multi-threaded process (a shell perhaps) gets told
    about the death of the _last_ thread to exit. This allows thread
    libraries that operate without an extra thread.

    There is a system call to translate thread IDs into process IDs.
    This can serve as getpid() in case a process forgets what it was,
    and it also helps libraries deal with the mess of old interfaces
    that don't know about the new multi-threaded process concept.
    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 12:38    [W:0.021 / U:1.408 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site