Re: SCO: "thread creation is about a thousand times faster than on native Linux"

From: Linus Torvalds (torvalds@transmeta.com)
Date: Thu Aug 24 2000 - 14:51:20 EST


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