From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 8 03:24:32 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2E544412 for ; Tue, 8 Jan 2013 03:24:32 +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 CEEF981E for ; Tue, 8 Jan 2013 03:24:31 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.5/8.14.5/NETPLEX) with ESMTP id r083OOXq043661; Mon, 7 Jan 2013 22:24:24 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.7 (mail.netplex.net [204.213.176.10]); Mon, 07 Jan 2013 22:24:24 -0500 (EST) Date: Mon, 7 Jan 2013 22:24:24 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Richard Sharpe Subject: Re: Is it possible to block pending queued RealTime signals (AIO originating)? In-Reply-To: <1357608470.6752.22.camel@localhost.localdomain> Message-ID: References: <1357608470.6752.22.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 03:24:32 -0000 On Mon, 7 Jan 2013, Richard Sharpe wrote: > Hi folks, > > I am running into a problem with AIO in Samba 3.6.x under FreeBSD 8.0 > and I want to check if the assumptions made by the original coder are > correct. > > Essentially, the code queues a number of AIO requests (up to 100) and > specifies an RT signal to be sent upon completion with siginfo_t. > > These are placed into an array. > > The code assumes that when handling one of these signals, if it has > already received N such siginfo_t structures, it can BLOCK further > instances of the signal while these structures are drained by the main > code in Samba. > > However, my debugging suggests that if a bunch of signals have already > been queued, you cannot block those undelivered but already queued > signals. > > I am certain that they are all being delivered to the main thread and > that they keep coming despite the code trying to stop them at 64 (they > get all the way up to the 100 that were queued.) > > Can someone confirm whether I have this correct or not? If true, could they not use sigwaitinfo() from a separate thread instead and just bypass having to use a signal handler altogether? That thread can either call sigwaitinfo() when it is ready to receive more signals, or block on a semaphore/CV/whatever while events are being processed. -- DE