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

[Adrian Chadd]

.. or you could abstract it out a bit and use freebsd's
aio_waitcomplete() or kqueue aio notification.

It'll then behave much saner.



adrian

On 7 January 2013 22:26, Richard Sharpe <rsharpe at richardsharpe.com> wrote:
> 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.
>
>
>
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"