signalling remote threads

[Tijl Coosemans]

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()?