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

[Daniel Eischen]

On Sun, 19 Aug 2007, Robert Watson wrote:

> On Sat, 18 Aug 2007, Daniel Eischen wrote:
>
>>> Stupid question, but ... why not?
>>> 
>>> First off, do you know for a fact that Wine is the only app out there that 
>>> needs the ability to kill off a thread in a seperate process, or has 
>>> nobody in the past cared enough to see other apps ported from Linux -> 
>>> FreeBSD to push for this sort of thing?
>> 
>> FreeBSD as well as Solaris and Linux (it looks like Linux only allows a 
>> thread group to be signaled) have gotten along without this API, and Wine 
>> seems to be the only target for this syscall.
>
> While I'm not familiar with the newer pthread code on Linux, I can say with 
> reasonable authority that the older implementation used the same ID space for 
> pids and thread IDs, since threads were tasks, and therefore Linux has always 
> supported directly signalling threads in other processes.

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.

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.

-- 
DE