From owner-cvs-all@FreeBSD.ORG Sun Aug 19 03:11:44 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 9C0FE16A41A; Sun, 19 Aug 2007 03:11:44 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 3926913C428; Sun, 19 Aug 2007 03:11:44 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.1/8.14.1/NETPLEX) with ESMTP id l7J3BbeA003344; Sat, 18 Aug 2007 23:11:37 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.netplex.net [204.213.176.10]); Sat, 18 Aug 2007 23:11:37 -0400 (EDT) Date: Sat, 18 Aug 2007 23:11:37 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: "Marc G. Fournier" In-Reply-To: <250D8A54B98F12158C71D8FE@ganymede.hub.org> Message-ID: References: <200708160526.l7G5Qg0b008022@repoman.freebsd.org> <46C4FD02.3090708@freebsd.org> <200708182118.37998.tijl@ulyssis.org> <20070818204223.D1234@fledge.watson.org> <250D8A54B98F12158C71D8FE@ganymede.hub.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: wine-freebsd@hub.org, src-committers@freebsd.org, cvs-src@freebsd.org, cvs-all@freebsd.org, Robert Watson , 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 Reply-To: Daniel Eischen 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 03:11:44 -0000 On Sat, 18 Aug 2007, Marc G. Fournier wrote: > - --On Saturday, August 18, 2007 20:51:57 -0400 Daniel Eischen > wrote: > >> You can say that about a lot of APIs, but that doesn't mean we should add >> them. This is a bit of a hack to satisfy one application (Wine) when there >> are other (perhaps harder) ways to skin the cat. We certainly don't want >> anything else using this API, so I'd advocate removing it. > > Stupid question, but ... why not? > > First off, do you know for a fact that Wine is the only app out there that > needs the ability to kill off a thread in a seperate process, or has nobody in > the past cared enough to see other apps ported from Linux -> FreeBSD to push > for this sort of thing? FreeBSD as well as Solaris and Linux (it looks like Linux only allows a thread group to be signaled) have gotten along without this API, and Wine seems to be the only target for this syscall. In general, a process shouldn't know about threads in another process and should use more well-defined and portable APIs for interprocess communication. There is no method (at least portable) of determining the threads in another process, so what API are you going to add to get this information? And once you do get it, how do you know if the thread id is still valid or even reused by the process (or even a different process). I could see adding this API or other APIs if they were for our own internal use (e.g., for use by libthr), but it's not. I guess there are more than a few syscalls like that (e.g., thr_*, kse_*). It'd be nice if we could keep them private for our own internal use. We sorta do this with the symbol mapping in libc, and perhaps by prepending some syscalls with "__" (__acl_*). But applications are free to use syscalls without going through libc. -- DE