On Tue, 2013-01-08 at 09:20 -0800, Adrian Chadd wrote: > On 8 January 2013 08:15, Richard Sharpe <rsha...@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. _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
