On Thu, 24 Aug 2000, Alan Cox wrote:
>
> Assuming we queue signals to arbitary threads then a single thread causing all
> the open/close/read events would queue open/close/read events onto arbitary
> signal queues. So thread 1 might see open open and thread 2 see close read-ready
No.
The current sys_kill() logic is not going away. The current "p->pid" is
not changing. None of this changes existing behaviour in the setup you
describe.
We would _add_ an interface to have a special thread group ID, and that
would only be used by sys_tgkill().
(An independent issue is then whether to decide to say "ok, we'll actually
put the new sys_tgkill() in the same position as the old sys_kill() in the
system call table, so that old user binaries automatically get the new
pthreads compatible kill capability". Note that this is also backwards
compatible, because sys_tgkill() and sys_kill() are actually 100% the same
as long as CLONE_PID isn't used ;)
So basically the only way to trigger the "thread-group-wide" signals would
be by doing so explicitly. Which we can choose to do on a case-by-case
basis inside the kernel, of course (so the tty layer may decide to use the
thread-group version of signal handling, while the SIGIO layer probably
really should _not_ do that).
We could make it more dynamic (ie make the exact behaviour a per-signal
flag or whatever), but that's beyond the scope of any 2.4.x "Let's get
LinuxThreads working well quickly" kind of discussion.
Linus
-
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:14 EST