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.
Well from what I understand, people want to be able to signal threads
individually and also signal the thread group with POSIX semantics. To
me it seems the cleanest implementation would be to have an extra
thread for accepting the signals for the task group. That way the
logic can stay out of the hair of the non-pthread things (and could
even be CONFIG_'ed out relatively painlessly for embedded uses)
It could certainly be done either way, I just suspect that having a
kernel thread looping on "schedule()" and coping with signals would
be easy.
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().
-Mitch
-
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:15 EST