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

[Daniel Eischen]

On Sat, 18 Aug 2007, Marc G. Fournier wrote:

> - --On Saturday, August 18, 2007 20:51:57 -0400 Daniel Eischen
> <deischen at freebsd.org> 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.
>
> 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.

In general, a process shouldn't know about threads in another process and
should use more well-defined and portable APIs for interprocess communication.
There is no method (at least portable) of determining the threads in another 
process, so what API are you going to add to get this information?  And
once you do get it, how do you know if the thread id is still valid or
even reused by the process (or even a different process).  I could see
adding this API or other APIs if they were for our own internal use
(e.g., for use by libthr), but it's not.  I guess there are more than a
few syscalls like that (e.g., thr_*, kse_*).  It'd be nice if we could
keep them private for our own internal use.  We sorta do this with the
symbol mapping in libc, and perhaps by prepending some syscalls with "__"
(__acl_*).  But applications are free to use syscalls without going
through libc.

-- 
DE