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>