[Async-sig] Asyncio, implementing a new fair scheduling reactor

[Pau Freixes]

Hi Nathaniel ...

Let me share my thoughts regarding your response

> It sounds like a more precise description of your scheduler would be
> "hierarchical FIFO"? i.e., there's a top-level scheduler that selects
> between "child" schedulers in round-robin/FIFO fashion, and each child
> scheduler is round-robin/FIFO within its schedulable entities? [1]
> Generally I would think of a "fair" scheduler as one that notices when
> e.g. one task is blocking the event loop for a long time when it runs,
> and penalizing it by not letting it run as often.

Agree with the controversial meaning of fair scheduling, I would
rename my title as Fair Queuing [1].

Regarding your notes, pretty interesting, and your thoughts about how
the current lack could be tackled in the near future. But, I would say
that these notes are more about flow control at the network level,
where mine was more oriented on business logic. I'm more inclined to
think that both works at different level and different granularity,
and are not excluding.

The draft that I presented is keen on allow the user - in a way of
pattern - to split and isolate resources from top to bottom. Yes, I
was thinking about different strategies that might give more
granularity and fine control to the user such as weighted partitions,
or even have just two queues  LOW and HIGH. But these last ones didn't
appeal to me for the following reasons:

- Give to the user the chance to mix partitions and weights might end
up having some code difficult to understand.
- The LOW and HIGH priority was too much restrictive. Give control to
the user to configure what is LOW and what is HIGH might end up also
having an overall performance worst than it was expected.

The idea behind the Fair queuing is: Give enough control to the user
but without taking the chance to screw up the whole thing.


> But also... isn't part of the point of a healthcheck that it *should*
> get slow if the system is overloaded?

Not really, the response of a health-check is dichotomic: Yes or No.
The problem on sharing resources between the health-check and the user
flow is when the last one impacts on the first one having, as a
result, false negatives.

The dynamic allocation of resources to scale up horizontally to suit
more traffic and reduce the pressure to the main flow is run by other
actors, that of course can rely on metrics that are sent out by the
user flow.

[1] https://en.wikipedia.org/wiki/Fair_queuing

-- 
--pau