[Python-ideas] Tulip / PEP 3156 event loop implementation question: CPU vs. I/O starvation

Sat Jan 12 18:18:45 CET 2013

On Fri, Jan 11, 2013 at 6:41 PM, Guido van Rossum <guido at python.org> wrote:
> Here's an interesting puzzle. Check out the core of Tulip's event
> loop:
> http://code.google.com/p/tulip/source/browse/tulip/unix_events.py#672
>> Specifically this does something like this:
>> 1. poll for I/O, appending any ready handlers to the _ready queue
>> 2. append any handlers scheduled for a time <= now to the _ready queue
>> 3. while _ready:
> handler = _ready.popleft()
> call handler
>> It is the latter loop that causes me some concern. In theory it is
> possible for a bad callback to make this loop never finish, as
> follows:
>> def hogger():
> tulip.get_event_loop().call_soon(hogger)
>
This is actually a useful pattern, not just a pathological "bad callback".
 If the function does some work before re-adding itself, it allows for
better multitasking kind of like doing the work in another thread (with a
starvation-free event loop). If the event loop starves IO in this case
it's difficult to get this kind of non-blocking background execution (you
have to use call_later with a non-zero timeout, slowing the work down
unnecessarily).
>> Because call_soon() appends the handler to the _ready queue, the while
> loop will never finish.
>> There is a simple enough solution (Tornado uses this AFAIK):
>> now_ready = list(_ready)
> _ready.clear()
> for handler in now_ready:
> call handler
>> However this implies that we go back to the I/O polling code more
> frequently.

In isolation, yes. Under real-world load, it's less clear. A zero-timeout
poll that has nothing to return is in some sense wasted work, but if
there's other stuff going on then we may just change the timing of the poll
calls rather than inserting additional ones.
>> So what's more important? Avoid I/O starvation at all cost or make the
> callbacks-posting-callbacks pattern efficient? I can see several
> outcomes of this discussion: we could end up deciding that one or the
> other strategy is always best; we could also leave it up to the
> implementation (but then I still would want guidance for what to do in
> Tulip); we could even decide this is so important that the user needs
> to be able to control the policy here (though I hate having many
> configuration options, since in practice few people bother to take
> control, and you might as well have hard-coded the default...).
>
I'm not sure it's worth the complexity to offer both, so I'd be inclined to
just have the starvation-free version.
-Ben
>> Thoughts? Do I need to explain it better?
>> --
> --Guido van Rossum (python.org/~guido)
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130112/54d6c7db/attachment.html>