cvs commit: src/sys/kern kern_thr.c syscalls.master src/sys/sys
rwatson at FreeBSD.org
Sun Aug 19 02:13:40 PDT 2007
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
University of Cambridge
More information about the cvs-all