Mitchell Blank Jr writes:
> Werner Almesberger wrote:
>> Where's the advantage over just making ordinary signal delivery
>> do the right thing ? The code's the same, and you don't give
>> user space any added flexibility.
This is a very reasonable solution.
> Well from what I understand, people want to be able to signal threads
> individually and also signal the thread group with POSIX semantics.
So we add a second system call.
> To me it seems the cleanest implementation would be to have an extra
> thread for accepting the signals for the task group.
...
> Another advantage is that you wouldn't need sys_tgkill() - just have
> getpid() return the thread group master's PID, since it can be shot
> at with a normal sys_kill().
The thread problem gets worse the more I study the code.
(so, yes, I've just started to attempt fixing this - anyone else?)
First of all, I'd hate to have the kernel enforce an N+1 or N model.
The kernel ought to be happy with either model.
The PID appears in many annoying places. Signals are just second
most obvious place, after the fork-exec-clone mess. PIDs get embedded
in structures that are part of the API. Lock owners, capability bit
granting, af_unix credentials, SysV IPC stuff... all use the PID.
Every use of PID must be examined to determine if it should keep
using Linux task IDs or if it should use the new POSIX PIDs.
Sometimes, as with kill(), we need both options. Other times,
one type of ID makes more sense than the other type does.
Getting back to signals... where can they be sent?
a. all tasks
b. all tasks except the task master (I like that term!)
c. any one task
d. any one task, not including the task master
e. the task master alone
POSIX has quite a bit to say about this, but maybe we don't want
to hard-wire the POSIX way into our kernel thread support.
We could let non-POSIX thread libraries choose other behaviors.
Oh, what if the task master is dead?
Cool problem:
Some threaded, uh, "thing" sends SIGSTOP to one of its threads.
The admin sends SIGSTOP to the whole group of tasks, then sends
SIGCONT to undo the SIGSTOP. Does the thread stopped earlier
get to continue, or does it somehow remain stopped?
-
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:17 EST