Posted Nov 24, 2010 22:02 UTC (Wed) by kleptog
In reply to: Async I/O
Parent article: Ghosts of Unix past, part 4: High-maintenance designs
The fundamental problem with AIO is that the block drivers aren't interruptible at their core. They need to run on a thread and block waiting on certain hardware operations.
Is that really true? I was under the impression that with modern hardware interfaces were becoming more network-like, with sending and receiving messages. You can have dozens of outstanding requests queued on a modern hard disk, I'm not sure why AIO is a big deal. Why is requesting data off a file on disk different from requesting a block from a network block device?
The messy part about POSIX AIO is more the interface, using signals again while they are completely inappropriate for the task (see the earlier article). Yes, you can emulate it with threads, but they have their own baggage. Glibc did aio that way for a while and injecting threads into an otherwise unthreaded program tends to have side-effects (on fork/exec, amongst others). The emulation sucked in other ways, like no more than one request outstanding per FD, WTF!
What I'd like to see is a message passing interface connecting you to the block device queue, where you submit your requests as messages and receive the data back as messages. Perhaps even a read giving you the data preceded by a header saying which FD it came from. That saves the kernel keeping pointers to user-space. send/recvmsg() seem especially suited.
Thanks for the kqueue tip, that looks like a solid solution.
to post comments)