Messages in this thread |  | | Date | Thu, 24 Aug 2000 12:51:20 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: SCO: "thread creation is about a thousand times faster than on native Linux" |
| |
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/
|  |