From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 8 02:46:06 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B0F10D5E for ; Tue, 8 Jan 2013 02:46:06 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id A2D306A1 for ; Tue, 8 Jan 2013 02:46:06 +0000 (UTC) Received: from xyf.my.dom (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r082k5jS057991 for ; Tue, 8 Jan 2013 02:46:06 GMT (envelope-from davidxu@freebsd.org) Message-ID: <50EB888A.2030802@freebsd.org> Date: Tue, 08 Jan 2013 10:46:34 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:14.0) Gecko/20120822 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Is it possible to block pending queued RealTime signals (AIO originating)? References: <1357608470.6752.22.camel@localhost.localdomain> In-Reply-To: <1357608470.6752.22.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list 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 02:46:06 -0000 On 2013/01/08 09:27, 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? > I am curious that how the code BLOCKs the signal in its signal handler ? AFAIK, after signal handler returned, original signal mask is restored, and re-enables the signal delivering, unless you change it in ucontext.uc_sigmask. Regards, David Xu