From owner-cvs-all@FreeBSD.ORG Sun Aug 19 18:19:18 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 B881A16A418; Sun, 19 Aug 2007 18:19:18 +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 82A1913C4A3; Sun, 19 Aug 2007 18:19:18 +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 661A54C73C; Sun, 19 Aug 2007 14:19:17 -0400 (EDT) Date: Sun, 19 Aug 2007 19:19:17 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Scott Long In-Reply-To: <20070819185019.M81759@fledge.watson.org> Message-ID: <20070819191731.N81759@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> <46C86D9A.9050705@samsco.org> <20070819185019.M81759@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Sun, 19 Aug 2007 18:30:51 +0000 Cc: wine-freebsd@hub.org, Kris Moore , 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 18:19:18 -0000 On Sun, 19 Aug 2007, Robert Watson wrote: > I think the misunderstanding here is in thinking that Wine is an application > that can program to the pthreads API and behave in a normal way. Instead, > think of it as including its own threads library implementing Windows > threading behavior. On the whole, the existing thread calls meet the needs > of Wine, and often it can access them via pthreads, but there are times when > it needs to *know* how threading works, and in those cases, accessing > threads via low-level system call like thr_kill2(2) or via ptrace(2) may be > entirely appropriate. > > Tijl's example of having aligned thread IDs for use between ptrace(2) and > the thr_*(2) system calls is a particularly good example of a case where the > clean pthreads abstraction (which has no notion of how to interact with > debuggers) isn't a good match. We have a plethora of low level threads > system calls that applications generally shouldn't touch -- rfork(2), > kse_*(2), thr_*(2), umtx_*(2), etc. Last time I checked, Valgrind on > FreeBSD did something very similar, relying on low-level umtx(2) system > calls. Just to follow up on this point: as with the other kse(2), thr(2), umtx(2), etc, interfaces, I think we should heavily discourage programmers from using them -- they are internal interfaces used to implement threading, and not general purpose application programming interfaces. I think adding a libpthread-layer interface for killing threads in other processes would be a mistake for all the reasons that Daniel and others have pointed out. Robert N M Watson Computer Laboratory University of Cambridge