signalling remote threads

[Julian Elischer]

Tijl Coosemans wrote:
> On Friday 09 March 2007 23:19, Julian Elischer wrote:
>> Tijl Coosemans wrote:
>>> On Friday 09 March 2007 18:18, Daniel Eischen wrote:
>>>> On Fri, 9 Mar 2007, Tijl Coosemans wrote:
>>>>> Is it somehow possible to send a signal to a specific thread in
>>>>> another process similar to the linux tkill and tgkill syscalls?
>>>>>
>>>>> I've seen the thr_kill call that takes an lwpid as argument, but
>>>>> it can't send a signal to another process can it?
>>>> No, it is not possible and it shouldn't be possible
>>>> as it's not portable.  From outside the process, you
>>>> can send a signal to another _process_ (which will
>>>> be delivered to one of its threads depending on
>>>> their signal masks), but not to a specific thread
>>>> in another process.
>>> Ok, thanks. The reason I asked is because Wine uses this to let the
>>> wineserver process (windows kernel) send signals to threads in a
>>> wine process.
>>>
>>> The only solution I see then is to have some sort of service thread
>>> in the receiving process to dispatch the signal. That would be a
>>> portable solution, but lots of work...
>> How does something external to a process identify a thread within
>> the process?
> 
> Wineserver plays the role of the windows kernel (more or less). It
> knows about all the (win32) threads in every wine process. Whenever
> a wine process creates a new thread it sends the thread id to the
> wineserver. On FreeBSD this is currently always -1. On Linux it is
> obtained with gettid(). This id is then later used with tgkill().
> 
>> And even if you could tell the threads appart, ho do you know which
>> one to signal?
> 
> Wineserver handles IPC calls (read: syscalls) from wine processes.
> An example where wineserver sends a signal to a specific threads is
> when some thread requests to suspend another thread.
> 
>> There is no portable way to identify threads in another process.
>> There is also no guarantee that the tread is even externally
>> visible. Take the example of a multiplexed threading library (such
>> as libc_r) which multiplexes all the threads onto a single user
>> process/thread. you basiclly HAVE to ask an agent within the process
>> to signal the right thread for you on such a system. If they are
>> doing things like that then they are basically writing for only
>> Linux.
> 
> So, in case of wineserver and wine, the (only?) portable way would be
> for wineserver to know all the pthread_self() identifiers, which can
> then be used in an IPC call to an agent in the wine process, that in
> turn uses pthread_kill()?

basically that would, at least be portable. 

It would be possible to do it (siggnal it directly) in libpthread 
if it were running in system_scope mode, (libprhtread can run in 2 modes) 
and it would be possible to do it if you linked with libthr too though 
I don't knwo all the details.