[Python-ideas] PEP 3156 EventLoop: hide details of iterations and idleness? (original) (raw)
Geert Jansen geertj at gmail.com
Tue Jan 22 09:04:30 CET 2013
- Previous message: [Python-ideas] PEP 3156 EventLoop: hide details of iterations and idleness?
- Next message: [Python-ideas] PEP 3156 EventLoop: hide details of iterations and idleness?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Mon, Jan 21, 2013 at 11:13 PM, Ben Darnell <ben at bendarnell.com> wrote:
While working on proof-of-concept tornado/tulip integration (https://gist.github.com/4582282), I found a few methods that could not easily be implemented on top of the tornado IOLoop because they rely on details that Tornado does not expose. While it wouldn't be hard to add support for these methods to Tornado, I would argue that they are unnecessary and expose implementation details, and so they are good candidates for removal from this already very broad interface.
First, runonce and calleveryiteration both expose the event loop's underlying iterations to the application. The trouble is that the duration of one iteration is so widely variable that it's not a very useful concept (and when implementing the EventLoop interface on top of some existing event loop these methods may not be available). When is it better to use runonce instead of just using calllater to schedule a stop after a short timeout, or calleveryiteration instead of callrepeatedly?
run_once() vs call_later(0) is probably the same thing and just an matter of API design. If Tornado has call_later() it might be able to emulate call_once() as call_later(0), depending on how call_once works. In Guido's latest code for example call_once() callbacks, when added inside a callback, will run in the next iteration. This makes call_soon() and call_later(0) the same.
call_every_iteration() vs call_repeatedly(): you really need both. I did a small proof of concept to integrate libdbus with the tulip event loop. I use call_every_iteration() to dispatch events every time after IO has happened. The idea is that events will always originate from IO, and therefore having a callback on every iteration is a convenient way to check for events that need to be dispatched. Using call_repeatedly() here is not right, because there may be times that there are 100s of events per second, and times there are none. There is no sensible fixed polling frequency.
If Tornado doesn't have infrastructure for call_every_iteration() you could emulate it with a function that re-reschedules itself using call_soon() just before calling the callback. (See my first point about when call_soon() callbacks are scheduled.)
If you want to see how event loop adapters for libev and libuv look like, you can check out my project here: https://github.com/geertj/looping
Regards, Geert
- Previous message: [Python-ideas] PEP 3156 EventLoop: hide details of iterations and idleness?
- Next message: [Python-ideas] PEP 3156 EventLoop: hide details of iterations and idleness?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]