From owner-cvs-all@FreeBSD.ORG Sun Aug 19 17:58:11 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 E876516A417; Sun, 19 Aug 2007 17:58:11 +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 B4ED113C491; Sun, 19 Aug 2007 17:58:11 +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 A72BF48DAE; Sun, 19 Aug 2007 13:58:10 -0400 (EDT) Date: Sun, 19 Aug 2007 18:58:10 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Scott Long In-Reply-To: <46C86D9A.9050705@samsco.org> Message-ID: <20070819185019.M81759@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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Sun, 19 Aug 2007 18:06:05 +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 17:58:12 -0000 On Sun, 19 Aug 2007, Scott Long wrote: > Robert's comparison to Linux is only half-valid. There's really no reason > to hold linux's clone/vfork threads up as a model to emulate via a new > first-class interface into the kernel. If you want to emulate it, compile > your app against the linux-threads package and be done with it. > > The Linux developers are moving beyond that primitive "threads" package > anyways and onto real threads and a complementary API to manage those > threads. So tkill and tgkill are interesting things to look at, not just > here but in the broader need to work with Linux both at a source and a > binary level. I believe that Dan also suggested something along this line > in his discussion about having Solaris-style (and thus linux-style) thread > groups, so I'm not exactly sure who is disagreeing with whom in Robert's > response. Thread groups do seem like a logical next step, but it's > impossible to say at this point whether the syscall API to support them > would at all be served by the syscall that was just added. If it isn't, > then this syscall becomes a 1-off orphan and a long-term liability to both > users and developers. That's what ultimately needs to be avoided. > > So, supporting Wine is definitely a good idea, and there's no doubt a good > solution available. It just makes me nervous when syscalls are added with > such little discussion and commitment. 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. Robert N M Watson Computer Laboratory University of Cambridge