signalling remote threads
julian at elischer.org
Fri Mar 9 22:30:25 UTC 2007
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
> 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? And even if you could tell the threads appart, ho do you know which
one to signal?
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.
> freebsd-threads at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-threads-unsubscribe at freebsd.org"
More information about the freebsd-threads