Date: Wed, 09 Jan 2013 07:21:10 -0800 From: Richard Sharpe <rsharpe@richardsharpe.com> To: Adrian Chadd <adrian@freebsd.org> Cc: Daniel Eischen <deischen@freebsd.org>, freebsd-hackers@freebsd.org Subject: Re: Is it possible to block pending queued RealTime signals (AIO originating)? Message-ID: <1357744870.8329.7.camel@localhost.localdomain> In-Reply-To: <CAJ-Vmom-SCMH8BEdgdHxuE7PZ194G7XyQypV8U4f7ome76pWJw@mail.gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1357744870.8329.7.camel>