Messages in this thread |  | | From | "Albert D. Cahalan" <> | Subject | Re: SCO: "thread creation is about a thousand times faster than on native Linux" | Date | Sat, 26 Aug 2000 18:43:17 -0400 (EDT) |
| |
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 majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |