From owner-freebsd-threads@FreeBSD.ORG Sat Mar 10 11:31:20 2007 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C329816A400; Sat, 10 Mar 2007 11:31:20 +0000 (UTC) (envelope-from tijl@ulyssis.org) Received: from thumbler.kulnet.kuleuven.ac.be (thumbler.kulnet.kuleuven.ac.be [134.58.240.45]) by mx1.freebsd.org (Postfix) with ESMTP id 534CC13C467; Sat, 10 Mar 2007 11:31:20 +0000 (UTC) (envelope-from tijl@ulyssis.org) Received: from localhost (localhost [127.0.0.1]) by thumbler.kulnet.kuleuven.ac.be (Postfix) with ESMTP id 3487A138223; Sat, 10 Mar 2007 12:31:19 +0100 (CET) Received: from smtps01 (octavianus.kulnet.kuleuven.ac.be [134.58.240.71]) by thumbler.kulnet.kuleuven.ac.be (Postfix) with ESMTP id 3AC211381E8; Sat, 10 Mar 2007 12:31:18 +0100 (CET) Received: from kalimero.kotnet.org (kalimero.kotnet.org [10.4.16.222]) by smtps01 (Postfix) with ESMTP id 064E82E68CB; Sat, 10 Mar 2007 12:31:18 +0100 (CET) Received: from kalimero.kotnet.org (kalimero.kotnet.org [127.0.0.1]) by kalimero.kotnet.org (8.13.8/8.13.8) with ESMTP id l2ABVHDj001879; Sat, 10 Mar 2007 12:31:17 +0100 (CET) (envelope-from tijl@ulyssis.org) From: Tijl Coosemans To: freebsd-threads@freebsd.org Date: Sat, 10 Mar 2007 12:31:11 +0100 User-Agent: KMail/1.9.5 References: <200703091515.27133.tijl@ulyssis.org> <200703092100.12199.tijl@ulyssis.org> <45F1DD68.8040103@elischer.org> In-Reply-To: <45F1DD68.8040103@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703101231.16407.tijl@ulyssis.org> X-Virus-Scanned: by KULeuven Antivirus Cluster Cc: Daniel Eischen , gerald@freebsd.org, Julian Elischer Subject: Re: signalling remote threads X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2007 11:31:20 -0000 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()?