Date: Mon, 7 Jan 2013 22:24:24 -0500 (EST) From: Daniel Eischen <deischen@freebsd.org> To: Richard Sharpe <rsharpe@richardsharpe.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Is it possible to block pending queued RealTime signals (AIO originating)? Message-ID: <Pine.GSO.4.64.1301072215400.14726@sea.ntplx.net> In-Reply-To: <1357608470.6752.22.camel@localhost.localdomain> References: <1357608470.6752.22.camel@localhost.localdomain>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.1301072215400.14726>