Date: Sat, 10 Mar 2007 12:31:11 +0100 From: Tijl Coosemans <tijl@ulyssis.org> To: freebsd-threads@freebsd.org Cc: Daniel Eischen <deischen@freebsd.org>, gerald@freebsd.org, Julian Elischer <julian@elischer.org> Subject: Re: signalling remote threads Message-ID: <200703101231.16407.tijl@ulyssis.org> In-Reply-To: <45F1DD68.8040103@elischer.org> References: <200703091515.27133.tijl@ulyssis.org> <200703092100.12199.tijl@ulyssis.org> <45F1DD68.8040103@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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()?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200703101231.16407.tijl>