On Dec 20, 2007 8:36 PM, Itamar Shtull-Trauring <itamar@itamarst.org> wrote:
I'm pretty sure you are mistaken. As I understood, libevent provides a portable API on top of whatever async I/O mechanisms there are on the underlying system, selecting the best available implementation.
For Linux, I believe this it currently uses epoll, kqueue on freebsd, or select() or poll() on older systems.
None of those are asynchronous IO. They allow efficient querying of readability/writeability, typically used with *non-blocking* IO.
Ah, right, I understand. Sorry about the noise then <:| Seems I've been using the wrong word for a while then. So is performance the only reason for preferring asynchronous i/o to non-blocking i/o?
In design pattern language they are "reactors", whereas async IO would be a "proactor." In API land you can tell the difference because with async APIs you have a callback: Twisted's Protocol/Transport APIs usually convert low-level change events (socket is readable) and non-blocking IO (reading the socket) to high-level async callbacks (dataReceived called with data).
Kernel level AIO, is that about the kernel providing that abstraction or is it using the hardware in some entirely different way? Hope you don't mind naive questions. cheers, Arnar