[Twisted-Python] Async file I/O with Linux & Twisted

Arnar Birgisson arnarbi at gmail.com
Thu Dec 20 16:13:26 EST 2007

On Dec 20, 2007 8:36 PM, Itamar Shtull-Trauring <itamar at 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.


More information about the Twisted-Python mailing list