[lkml]   [2000]   [Aug]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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


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

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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:1.143 / U:0.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site