Is it possible to block pending queued RealTime signals (AIO originating)?

[Daniel Eischen]

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