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

[Tijl Coosemans]

On Friday 17 August 2007 04:33:07 Daniel Eischen wrote:
> On Friday 17 August 2007 03:42:26 David Xu wrote:
>> Daniel Eischen wrote:
>>> On Thu, 16 Aug 2007, Xin LI wrote:
>>>> Daniel Eischen wrote:
>>>>> On Thu, 16 Aug 2007, David Xu wrote:
>>>>>> davidxu     2007-08-16 05:26:42 UTC
>>>>>>
>>>>>>  FreeBSD src repository
>>>>>>
>>>>>>  Modified files:
>>>>>>    sys/kern             kern_thr.c syscalls.master
>>>>>>    sys/sys              thr.h
>>>>>>  Log:
>>>>>>  Add thr_kill2 syscall which sends a signal to a thread in
>>>>>>  another process.
>>>>>
>>>>>
>>>>> I do not think this is a good idea.  There is no such thing in
>>>>> Solaris, only Linux seems to have this hideous idea of an API.
>>>>
>>>>
>>>> I think this would be helpful for applications like Wine.  Is
>>>> there any other way to implement the semantics?
>>>
>>>
>>> I realize what it's for, and I don't agree that it belongs in the
>>> tree.  There are other forms of interprocess communication, pipes,
>>> sockets, even msg queues.  I'm sure you can find a few ways to send
>>> a message to a process to say "send signal X to thread Y" if you
>>> really wanted to.  It looks like even Linux makes you use a thread
>>> group, not a thread.


The tgkill() syscall in Linux takes a tgid and a pid as arguments,
where pid can be a thread id (obtained with gettid()).


>>> I don't see where this was discussed on -arch or -current, but
>>> maybe I missed that thread.
>>
>>
>> I've CCe'd Tijl Coosemans to check if there is another way to
>> implement the feature in WINE instead of in kernel. in fact, I have
>> delayed the the change for a few days, I was thinking you know the
>> patch, but the fact is not now. PS, the feature is not required by
>> libthr. ;-)
>
>
> Yes, I know it's not needed by libthr :-)  I would think you could
> use mq_open(), mq_notify() with sigev_notify = SIGEV_SIGNAL, etc.
> When the receiving process gets the signal, it reads the message
> queue to get the target thread id and the signal to send to it.
> 
> It would be nice if we (FreeBSD) did have thread groups, and the
> ability to (soft) bind them to specific CPUs or CPU sets, ala Solaris
> processor_bind(), pset_bind(), etc.  Once you have these, then I can
> perhaps see a thrgrp_signal() or something similar since the thread
> group would already be managable outside the context of a process.


To be honest, I'm not entirely fond of adding this syscall either, but
from an engineering point of view, it's really the easiest and cheapest
solution right now.

POSIX message queues aren't needed. Sigqueue() with sigval set to the
thread id would be enough. Then whichever thread receives the signal
can either handle it or dispatch it using thr_kill().

Sigqueue() doesn't exist in 6-STABLE though and as I understood will
never be MFC'd, because it involves too many other things (signal
queueing, ksiginfo,...), whereas thr_kill2() is entirely isolated and
trivial to merge.

Perhaps it should be stressed in documentation that this syscall is
only meant for Wine and to be removed at some point when better
solutions become available. I want to test this sigqueue solution some
more, because the indirection in signal delivery causes trouble when a
thread signals itself. I guess this would have to be special-cased
somehow then.