Iguess the short answers is that it is not implemented and probably it won't.
There are certain applications that would certainly benefit from aio. The one I can think of (it is the one I use the most) is I/O trace replay. But I am sure that there are plenty of applications that can benefit from this facility. It is true that aio can be easily implemented having an I/O handler thread. But it is always nice to have a library that do it for you ;) Thanks for your responses, Luis On Fri, Dec 4, 2009 at 5:45 PM, Ted Unangst <ted.unan...@gmail.com> wrote: > On Fri, Dec 4, 2009 at 4:45 PM, Todd T. Fries <t...@fries.net> wrote: >> Does aio really require threading? > > In some sense, yes, in others, no. aio is designed so you don't need > (userland) threads. > > "Normally" you'd write your server to use non-blocking io. But that > doesn't work with files on disk. How can it? With network sockets, > you have somebody on the other end pushing data into your pipe which > the kernel buffers. But the file system isn't going to read stuff > from disk until you ask for it, there's no "somebody else" pushing > data at you. That's what aio is for. It starts up a disk request > without waiting for it. Then you can come back and get the result. > Think of it as preemptive polling. Instead of calling select()/poll() > to find out what's _ready_ for io, you call aio and then later it > tells you what's _done_ with io. > > A normal implementation would be purely kernel based, with a few new > syscalls. But the kernel would still need to keep track of all the > buffers and io requests. So at that level, there's still something > resembling threading. > > This is all fairly easy to fake in userland. When somebody calls > aio_read(), just spin up a thread that calls read() until done. The > main process goes on with its work, magic happens in the background. > Of course, this requires the ability for one thread to execute while > another is blocked, which the uthreads implementation we have doesn't > have.
