cvs commit: src/sys/kern kern_thr.c syscalls.master src/sys/sys

[Tijl Coosemans]

On Sunday 19 August 2007 16:44:09 Daniel Eischen wrote:
> Thread id's (as visible to an application) are not required to be
> something that is known by the kernel.  They certainly are not in
> libkse and libc_r, and I don't think they are in libthr either.
> This API won't work with libkse (or libc_r if we care) and isn't
> guaranteed to work with any future libthreadX.

Right, but this is irrelevant. Wine wants all threads to be visible
by the kernel (system scope), and uses the kernel thread id to send
signals, but also with ptrace for instance.

> POSIX has well defined behavior with regard to signaling, and
> this certainly bypasses that.  If we want to add a more well thought
> out set of APIs for thread groups that can (in the future) support
> CPU binding and scheduling, then that's OK.  But the API as committed
> is a hack that solves one particular problem that can be solved in
> other (more portable) ways.  sigqueue() was mentioned as a possible
> solution earlier.

There's one immense downside to the sigqueue method though. When you
call kill(2) you know the signal has been queued when the call returns
and you know the signal will be posted when the thread next crosses the
kernel-to-user boundary. With the sigqueue method signal delivery
becomes entirely asynchronous and that introduces timing issues.

I also don't see this syscall as a hack. It isn't in any portable
specification, but it is an understandable extension to kernel threads,
which the patch clearly shows because it isn't adding anything new.
It's basically only exporting functionality that was already there and
will never go away either, because the kernel will always need to send
signals to threads.