From owner-cvs-all@FreeBSD.ORG Sun Aug 19 16:38:03 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 71A4F16A418; Sun, 19 Aug 2007 16:38:03 +0000 (UTC) (envelope-from tijl@ulyssis.org) Received: from mailrelay005.isp.belgacom.be (mailrelay005.isp.belgacom.be [195.238.6.171]) by mx1.freebsd.org (Postfix) with ESMTP id 35D9C13C4A7; Sun, 19 Aug 2007 16:38:01 +0000 (UTC) (envelope-from tijl@ulyssis.org) Received: from 204.27-245-81.adsl-dyn.isp.belgacom.be (HELO kalimero.kotnet.org) ([81.245.27.204]) by mailrelay005.isp.belgacom.be with ESMTP; 19 Aug 2007 18:38:00 +0200 Received: from localhost (localhost [127.0.0.1]) by kalimero.kotnet.org (8.14.1/8.14.1) with ESMTP id l7JGbuor062403; Sun, 19 Aug 2007 18:37:56 +0200 (CEST) (envelope-from tijl@ulyssis.org) From: Tijl Coosemans To: Daniel Eischen Date: Sun, 19 Aug 2007 18:37:55 +0200 User-Agent: KMail/1.9.7 References: <200708160526.l7G5Qg0b008022@repoman.freebsd.org> <20070819092923.X65240@fledge.watson.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708191837.56412.tijl@ulyssis.org> Cc: wine-freebsd@hub.org, src-committers@freebsd.org, cvs-src@freebsd.org, cvs-all@freebsd.org, "Marc G. Fournier" , Robert Watson , David Xu , 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:38:03 -0000 On Sunday 19 August 2007 16:44:09 Daniel Eischen wrote: > Thread id's (as visible to an application) are not required to be > something that is known by the kernel. They certainly are not in > libkse and libc_r, and I don't think they are in libthr either. > This API won't work with libkse (or libc_r if we care) and isn't > guaranteed to work with any future libthreadX. Right, but this is irrelevant. Wine wants all threads to be visible by the kernel (system scope), and uses the kernel thread id to send signals, but also with ptrace for instance. > POSIX has well defined behavior with regard to signaling, and > this certainly bypasses that. If we want to add a more well thought > out set of APIs for thread groups that can (in the future) support > CPU binding and scheduling, then that's OK. But the API as committed > is a hack that solves one particular problem that can be solved in > other (more portable) ways. sigqueue() was mentioned as a possible > solution earlier. There's one immense downside to the sigqueue method though. When you call kill(2) you know the signal has been queued when the call returns and you know the signal will be posted when the thread next crosses the kernel-to-user boundary. With the sigqueue method signal delivery becomes entirely asynchronous and that introduces timing issues. I also don't see this syscall as a hack. It isn't in any portable specification, but it is an understandable extension to kernel threads, which the patch clearly shows because it isn't adding anything new. It's basically only exporting functionality that was already there and will never go away either, because the kernel will always need to send signals to threads.