From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 8 06:26:57 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 A33E97F1 for ; Tue, 8 Jan 2013 06:26:57 +0000 (UTC) (envelope-from rsharpe@richardsharpe.com) Received: from zmail.servaris.com (zmail.servaris.com [107.6.51.160]) by mx1.freebsd.org (Postfix) with ESMTP id 4F2E6D55 for ; Tue, 8 Jan 2013 06:26:56 +0000 (UTC) Received: (qmail 48241 invoked by uid 89); 8 Jan 2013 06:26:55 -0000 Received: from unknown (HELO ?192.168.2.23?) (rsharpe@richardsharpe.com@108.225.16.199) by mail.richardsharpe.com with ESMTPA; 8 Jan 2013 06:26:55 -0000 Subject: Re: Is it possible to block pending queued RealTime signals (AIO originating)? From: Richard Sharpe To: Daniel Eischen In-Reply-To: References: <1357608470.6752.22.camel@localhost.localdomain> Content-Type: text/plain; charset="UTF-8" Date: Mon, 07 Jan 2013 22:26:52 -0800 Message-ID: <1357626412.6752.24.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org 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 06:26:57 -0000 On Mon, 2013-01-07 at 22:24 -0500, Daniel Eischen wrote: > 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. So, I guess that what I want is something that will continue to work for both Linux and FreeBSD with minimal code divergence ... I guess I need to write a simpler program to check what the deal is.