[Python-ideas] PEP 3156 EventLoop: hide details of iterations and idleness?

[Geert Jansen]

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, run_once and call_every_iteration 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 run_once
> instead of just using call_later to schedule a stop after a short timeout,
> or call_every_iteration instead of call_repeatedly?

- 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