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.
