Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 09 Jan 2013 10:20:03 -0800
From:      Julian Elischer <julian@freebsd.org>
To:        Richard Sharpe <rsharpe@richardsharpe.com>
Cc:        Daniel Eischen <deischen@freebsd.org>, freebsd-hackers@freebsd.org, Adrian Chadd <adrian@freebsd.org>
Subject:   Re: Is it possible to block pending queued RealTime signals (AIO originating)?
Message-ID:  <50EDB4D3.2060000@freebsd.org>
In-Reply-To: <1357744870.8329.7.camel@localhost.localdomain>
References:  <1357608470.6752.22.camel@localhost.localdomain> <Pine.GSO.4.64.1301072215400.14726@sea.ntplx.net> <1357626412.6752.24.camel@localhost.localdomain> <CAJ-VmomN5G70ftbV-uETYwUV7U6zLq%2BUKdav%2BM_B9HYB7HuEpQ@mail.gmail.com> <1357661755.6752.32.camel@localhost.localdomain> <CAJ-Vmom-SCMH8BEdgdHxuE7PZ194G7XyQypV8U4f7ome76pWJw@mail.gmail.com> <1357744870.8329.7.camel@localhost.localdomain>

next in thread | previous in thread | raw e-mail | index | archive | help
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@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@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
>




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50EDB4D3.2060000>