On Fri, 8 Aug 2008 08:04:11 +1000 "ronnie sahlberg" <ronniesahlberg at gmail.com> wrote: > 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. We did the similar thing. We don't fork every time we get a request. Instead we keep several processes to perform requests. But using a pipe is not the fastest way. I really like to move to the real AIO solution. |