From owner-freebsd-threads@FreeBSD.ORG Sat Mar 10 15:15:34 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 D749C16A407 for ; Sat, 10 Mar 2007 15:15:34 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outK.internet-mail-service.net (outK.internet-mail-service.net [216.240.47.234]) by mx1.freebsd.org (Postfix) with ESMTP id A245113C46B for ; Sat, 10 Mar 2007 15:15:34 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Sat, 10 Mar 2007 06:48:59 -0800 Received: from [192.168.2.5] (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 7D14F125B84; Sat, 10 Mar 2007 07:15:32 -0800 (PST) Message-ID: <45F2CB94.6070805@elischer.org> Date: Sat, 10 Mar 2007 07:15:32 -0800 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Tijl Coosemans References: <200703091515.27133.tijl@ulyssis.org> <200703092100.12199.tijl@ulyssis.org> <45F1DD68.8040103@elischer.org> <200703101231.16407.tijl@ulyssis.org> In-Reply-To: <200703101231.16407.tijl@ulyssis.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , gerald@freebsd.org, freebsd-threads@freebsd.org 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 15:15:35 -0000 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.