[Python-ideas] The async API of the future

Sam Rushing sam-pydeas at rushing.nightmare.com
Mon Nov 5 20:30:40 CET 2012

On 11/4/12 8:11 AM, Ben Darnell wrote:
> The extra system calls add up.  The interface of Tornado's IOLoop was
> based on epoll (where the internal state is roughly a mapping {fd:
> event_set}), so it requires more register/unregister operations when
> running on kqueue (where the internal state is roughly a set of (fd,
> event) pairs).  This shows up in benchmarks of the HTTPServer; it's
> faster on platforms with epoll than platforms with kqueue.  In
> low-concurrency scenarios it's actually faster to use select() even
> when kqueue is available (or maybe that's a mac-specific quirk).
Just so I have this right, you're saying that HTTPServer is slower on
kqueue because of the IOLoop design, yes?

I've just looked over the epoll interface and I see at least one huge
difference compared to kqueue: it requires a system call for each fd
registration event.  With kevent() you can accumulate thousands of
registrations, shove them into a single kevent() call and get thousands
of events out.  It's a little all-singing-all-dancing, but it's hard to
imagine a way to do it using fewer system calls. 8^)


More information about the Python-ideas mailing list