On Fri, Aug 8, 2008 at 4:14 AM, FUJITA Tomonori <fujita.tomonori at lab.ntt.co.jp> wrote: > On Wed, 6 Aug 2008 18:06:26 +0300 > "Alexander Nezhinsky" <nezhinsky at gmail.com> wrote: > >> On Wed, Jul 30, 2008 at 10:04 AM, FUJITA Tomonori >> <fujita.tomonori at lab.ntt.co.jp> wrote: >> >> > the future... We have it just because Linux AIO is not good enough >> > now. >> >> Can you explain a bit what's wrong with the current Linux AIO implementation. >> Why bs_aio.c is implemented using syscall(__NR_io_*)? >> What is wrong with the aio_read/aio_write and friends? > > > I think that that's Posix AIO, which glibc implemented. It's slower > than the kernel AIO support. A big problem about it for us is event > notification. We can't get AIO completion events via a file descriptor > (so that we can't use poll/epoll with it). How can we wait for both > network events and AIO events at the same time? What about setting up a pipe, forking, doing the the i/o in the child and then writing a byte of data to the pipe when the command completed. The parent can then "wait for the 'AIO' to complete by waiting on a file descriptor" like normal. forks are cheap under linux. I do this all the time in ctdb which is very hard real time and which can not ever call any function that may block from the main daemon. (== read/write/fcntl/waitpid,...) This is how samba 3 does AIO as well since the real AIO layer on many distribution versions are "suboptimal". |