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

[Julian Elischer]

On 1/9/13 7:21 AM, Richard Sharpe wrote:
> On Tue, 2013-01-08 at 09:20 -0800, Adrian Chadd wrote:
>> On 8 January 2013 08:15, Richard Sharpe <rsharpe at richardsharpe.com> wrote:
>>> On Tue, 2013-01-08 at 07:36 -0800, Adrian Chadd wrote:
>>>> .. or you could abstract it out a bit and use freebsd's
>>>> aio_waitcomplete() or kqueue aio notification.
>>>>
>>>> It'll then behave much saner.
>>> Yes, going forward that is what I want to do ... this would work nicely
>>> with a kqueue back-end for Samba's tevent subsystem, and if someone has
>>> not already written such a back end, I will have to do so, I guess.
>> Embrace FreeBSD's nice asynchronous APIs for doing things! You know you want to!
>>
>> (Then, convert parts of samba over to use grand central dispatch... :-)
>>
>> Seriously though - I was doing network/disk IO using real time signals
>> what, 10 + years ago on Linux and it plain sucked. AIO + kqueue +
>> waitcomplete is just brilliant. kqueue for signal delivery is also
>> just brilliant. Just saying.
> The problem with a fully event-driven approach is that it will not work,
> it seems to me. Eventually, you find something that is not async and
> then you have to go threaded. (Because handling multiple clients in one
> process is very useful and you do not want client-A's long-running op
> preventing client-B's short-running op from being serviced.)
>
> Then, you run into problems like Posix's insistence that all threads in
> a process must use the same credentials (ie, uid and gids must be the
> same across all threads), although there is a hack on Linux to work
> around this behind glibc's back.

The best implementation of an async framework I've seen is the one 
that Alan Cox
and friends wrote in the code they sold to IronPort/Cisco.

It'd be nice if we could get that extracted out and donated/included 
into something
generally available..  even had a #ifdef Linux code path..

>
> _______________________________________________
> 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"
>