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

[Dustin J. Mitchell]

On Sat, Jan 12, 2013 at 8:01 AM, Markus <nepenthesdev at gmail.com> wrote:
> Adding a poll-able descriptor to the the loop will eval it in the next
> iteration of the loop, so why make a difference with timers?
> Define call_soon to be called in the next iteration - not in the same.
>
> Basically every modification of the event loop should be evaluated in
> the next iteration, not the same.

We're looking for a "fair" scheduling algorithm here, and I think this
describes it.  Everything else should be an optimization from here.

For example, if the event loop "detects" that it is CPU-bound, perhaps
it skips some fraction of the relatively expensive calls to the IO
check.  I have no idea how to do such "detection" efficiently.  Maybe
just count the number of consecutive IO checks with timeout=0 that
returned no actionable IO, and skip that number of checks.

run_ready_queue()
check_io(timeout=0) -> no IO, counter becomes 1
run_ready_queue()
(skip 1)
run_ready_queue()
check_io(timeout=0) -> no IO, counter becomes 2
run_ready_queue()
(skip 1)
run_ready_queue()
(skip 2)
run_ready_queue()
check_io(timeout=0) ...

There would be some limits, of course, and this should probably be
based on time, not cycles.  It's not clear what to do when IO *does*
occur -- divide the counter by 2?  At any rate, this is an O(1) change
to the the event loop that would get some interesting adaptive
behavior, while still maintaining its fairness.

IMHO the PEP should leave this unspecified, perhaps suggesting only
that event loops have clear documentations regarding their fairness.
Then users can select event loops based on their needs.

Dustin