From owner-cvs-all@FreeBSD.ORG Sun Aug 19 16:24:32 2007 Return-Path: Delivered-To: cvs-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0BC516A419; Sun, 19 Aug 2007 16:24:32 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 72C7A13C457; Sun, 19 Aug 2007 16:24:32 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 0DC644AB3C; Sun, 19 Aug 2007 12:24:32 -0400 (EDT) Date: Sun, 19 Aug 2007 17:24:31 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Kris Moore In-Reply-To: <46C863C5.6090906@comcast.net> Message-ID: <20070819170957.H81759@fledge.watson.org> References: <200708160526.l7G5Qg0b008022@repoman.freebsd.org> <46C4FD02.3090708@freebsd.org> <200708182118.37998.tijl@ulyssis.org> <20070818204223.D1234@fledge.watson.org> <46C7A9A4.5090404@samsco.org> <20070819095302.D66918@fledge.watson.org> <46C863C5.6090906@comcast.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Sun, 19 Aug 2007 17:32:54 +0000 Cc: wine-freebsd@hub.org, Scott Long , src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org, Daniel Eischen , David Xu , Tijl Coosemans , Xin LI Subject: Re: cvs commit: src/sys/kern kern_thr.c syscalls.master src/sys/sys X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2007 16:24:32 -0000 On Sun, 19 Aug 2007, Kris Moore wrote: > That being said, most of the technical details are a bit over my head, but I > will add my $0.02 to this. Whatever the solution, there needs to be a > working solution in the end. If there's a better, more portable way to do > this, then by all means lets get it done. If nobody can or will write this > solution, then lets not just drop the original patch. A fix is greatly > needed either way, so I hope this is added in the very near future. Let me provide a bit more background for those who are just joining the conversation, as it has been going on since around March. (You can find fragments on the freebsd-threads list, etc). The underlying requirement here is for Wine to be able to suspend threads of the emulation process -- this is not a requirement I have any specific insight into, so can't justify it, but it seems a fairly reasonable thing to want to do. In Linux, suspending threads in a remote process is easy, because threads are processes, so signals can be delivered directly to specific threads in a target process using kill(2). This same functionality is available in Mac OS X via thread/task ports, and possibly in Solaris via procfs (I agree with Dan's reading that the _lwp_kill(2) system call in Solaris doesn't look like it can target remote process threads, but the debugging interfaces certainly can, and Wine is full of debugging interface use). As a more portable solution, sigqueue(2) can be used -- this is a POSIX realtime signaling interface that, among other things, allows a data value to be passed to the receiveing process. This would allow a proxy thread in the emulated process to "receive" the signal and then forward the signal to a specific thread within the same process. However, sigqueue(2) is available only in FreeBSD 7.x, and has been determined to be sufficiently complex to not be MFC'able. This leaves FreeBSD 6.x, which neither implement the richer signalling service, nor direct signal delivery to target threads. An obvious quick solution here is to add a system call to provide equivilent functionality to that in Linux, Mac OS X, Solaris, etc -- allow direct delivery of a signal to a specific target thread in a remote process. thr_kill2() does this in the expectedly straight forward way, but specific to libthr, as only libthr offers a 1:1 threading model in which the kernel is sufficiently aware of threads as to offer a useful way to signal them. You can imagine other schemes for forwarding signals to threads in a remote process that are only marginally more complicated than using sigqueue, such as having a proxy listening on an IPC pipe or the like. I can't really comment on the impact to Wine code of doing this. BTW, Wine already has to know a lot about the internals of operating systems and processes in order to do what it does -- how to lay out address spaces, using the ptrace interfaces to control and manage threads, etc. So I'm not sure I buy that we should expect Wine to conform to portable interfaces, or that portable interfaces should be able to express what Wine needs: it is doing something pretty inherrently non-portable. However, it could be that we could avoid introducing more non-portable interfaces through more Wine rewriting. Robert N M Watson Computer Laboratory University of Cambridge