Well you don't have asynchronous sendfile or splice. You don't have asynchronous stat/opendir/readdir/... as well. And the interface is not the same depending on the fd type. I don't think that AIO will work on something different from regular file.
Do you have any news about syslets?
IMHO asynchronous file I/O is still a mess on Linux.
As already stated in this thread the POSIX-AIO is implemented in user-space with a pool of blocking threads. The reason why it is not using the Kernel-AIO is the lack of features in AIO.
There are 3 reasons not to use the Kernel-AIO:
1. It only works with the O_DIRECT-flag, which means no buffering and very slow I/O.
2. Kernel-AIO needs support of the file-system in the kernel. Which file-systems are supported is a little bit of a mystery. Does CIFS or NFS support it?
3. When you finally use it it only runs on Linux, but not on BSD-systems.
I come from a windows background and I have to admit that the IO-Completion-Ports (IOCP) is a much superior API compared with what Linux has to offer. It works since Windows 2000, supports sockets and ALL kind of file-handles.
The Kernel-AIO moves the right direction, but the progress is very slow and hardly anybody is using it.
I wrote a high-performance-server on windows and wonder how I would have achieved the asynchronous file-I/O on Linux.
Why would you need AIO specifically - ie, why would it be better than say epoll + threads?
It's also much more complex and so bug-prone.
Okay, so say you're doing a lot of writing of files to a slow HDD. What do you gain from AIO when compared to regular O_NONBLOCK?
I have worked with big projects which used blocking I/O and with ones that used a completely asynchronous approach. In the end the asynchronous design was accepted by much more developers because they saw the benefit.
IMHO it is not hard to develop programs which use an asynchronous I/O approach. The main reason that a lot of people think it is more complex and bug-prone is because pretty much ALL examples of I/O (sockets or files) are blocking and it is hard to find good examples of the async way. That's why everbody starts with blocking I/O until they find out that it is not the best solution.
I can encourage everybody who is interested in the topic to look at the boost::asio library which is an excellent platform-independent API for asynchronous I/O. (but no async file I/O on linux)