From owner-cvs-all@FreeBSD.ORG Sun Aug 19 00:49:19 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 36CEC16A420; Sun, 19 Aug 2007 00:49:19 +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 CEDC313C458; Sun, 19 Aug 2007 00:49:18 +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 l7J0n6k1009733; Sat, 18 Aug 2007 20:49:07 -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 20:49:07 -0400 (EDT) Date: Sat, 18 Aug 2007 20:49:06 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Tijl Coosemans In-Reply-To: <200708182118.37998.tijl@ulyssis.org> Message-ID: References: <200708160526.l7G5Qg0b008022@repoman.freebsd.org> <46C4FD02.3090708@freebsd.org> <200708182118.37998.tijl@ulyssis.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, David Xu , Xin LI Subject: Re: cvs commit: src/sys/kern kern_thr.c syscalls.master src/sys/sys thr.h 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 00:49:19 -0000 On Sat, 18 Aug 2007, Tijl Coosemans wrote: > On Friday 17 August 2007 04:33:07 Daniel Eischen wrote: >> Yes, I know it's not needed by libthr :-) I would think you could >> use mq_open(), mq_notify() with sigev_notify = SIGEV_SIGNAL, etc. >> When the receiving process gets the signal, it reads the message >> queue to get the target thread id and the signal to send to it. >> >> It would be nice if we (FreeBSD) did have thread groups, and the >> ability to (soft) bind them to specific CPUs or CPU sets, ala Solaris >> processor_bind(), pset_bind(), etc. Once you have these, then I can >> perhaps see a thrgrp_signal() or something similar since the thread >> group would already be managable outside the context of a process. > > > To be honest, I'm not entirely fond of adding this syscall either, but > from an engineering point of view, it's really the easiest and cheapest > solution right now. That doesn't mean we should have added it. Our APIs that ship for 7.0 need to be maintained for compatibility, and this API is to satisfy just one application (Wine), and only for some of those applications that are run under it. > POSIX message queues aren't needed. Sigqueue() with sigval set to the > thread id would be enough. Then whichever thread receives the signal > can either handle it or dispatch it using thr_kill(). > > Sigqueue() doesn't exist in 6-STABLE though and as I understood will > never be MFC'd, because it involves too many other things (signal > queueing, ksiginfo,...), whereas thr_kill2() is entirely isolated and > trivial to merge. > > Perhaps it should be stressed in documentation that this syscall is > only meant for Wine and to be removed at some point when better > solutions become available. I want to test this sigqueue solution some > more, because the indirection in signal delivery causes trouble when a > thread signals itself. I guess this would have to be special-cased > somehow then. I would rather just use sigqueue in 7.0 if necessary and drop support for some set of applications run under Wine in 6.0. We shouldn't be adding hacks like this to suit just one application... -- DE