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

[Robert Watson]

On Sat, 18 Aug 2007, Scott Long wrote:

>> You can say that about a lot of APIs, but that doesn't mean we should add 
>> them.  This is a bit of a hack to satisfy one application (Wine) when there 
>> are other (perhaps harder) ways to skin the cat.  We certainly don't want 
>> anything else using this API, so I'd advocate removing it.
>
> I'm in strong agreement here.  David?

This work was done by Tijl at the request of the PC-BSD guys, who would like 
to be able to run windows applications out of the box on PC-BSD for their next 
release (impending).  David then reviewed and committed the patch giving it 
his approval.  The goal here was to avoid having the PC-BSD people have to run 
around with additional system call patches for the forseeable future, and to 
avoid requiring PC-BSD to fork the FreeBSD kernel to do that.

Given that many systems do support sending signals to specific threads in 
other processes, it may be worth surveying how it's done.  In Linux, 
historically it was done via kill(2) since processes were threads; the 
tgkill() interface has probably only been added because it represents a new 
grouping that doesn't fit the "negative pids are specific process groups, -1 
is all other processes, 0 is the current process group, and positive pids are 
specific processes".  In Mac OS X, signals can be delivered using a thread 
port, which is most easily done using the current process since the thread 
ports will be lying around anyway in the thread package, but also works for 
other processes as you can retrieve the thread ports of other processes using 
their task ports, which can be retrieved in turn using task_for_pid().  I'm 
not familiar with Solaris or Windows.

Robert N M Watson
Computer Laboratory
University of Cambridge