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/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:18 EST