Fair chaining APIs about futures-concurrency

[eholk]

Adding something like priority_hint to the Future trait seems pretty similar to the size_hint method on Iterator: https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.size_hint

[eholk]

One idea I had was to add an additional trait, something like this:

trait SchedulingWeight {
    fn scheduling_weight(&self) -> usize;
}

Then for tuples we'd have something like:

impl<A, B> SchedulingWeight for (A, B)
where
    A: SchedulingWeight,
    B: SchedulingWeight,
{
    fn scheduling_weight(&self) -> usize {
        self.0.scheduling_weight() + self.1.scheduling_weight()
    }
}

In the implementation of Future for (A, B), we could set it up so that if A::scheduling_weight() returns 1 and B::scheduling_weight() returns 2, then we poll B twice as often as we poll A.

There are some significant challenges with this approach. Mainly, most futures do not implement SchedulingWeight (in fact, all futures do not since the trait does not exist 😃), so we don't have a good way of graceful degradation. We might be able to work around a lot of the issues, but I think we're likely to end up with another sandwich problem where you have a Future + SchedulingWeight container that contains a Future that contains a Future + SchedulingWeight, and then we lose all the weighting information for the inner future.

So I think a more workable solution is to extend the future trait with a scheduling_weight (or maybe scheduling_hint or scheduling_weight_hint or priority_hint) method that has a default impl that returns 1. That way, by default we get the current behavior, but if futures want to provide more precise information they can override the method.

Also, if Rust gets impl specialization or refinement, that might open some other options up to us.

[yoshuawuyts]

I'm re-visiting some of the outstanding issues on this repo, and I didn't get around to saying it last time: but I really like the idea of a scheduling_weight method on future. this would allow us to solve the fairness issue in a transparent way for all futures combinators, in a way that would compose really nicely.

Maybe we should ACP that to get an experiment going?

[eholk]

I think an experiment seems like a good idea. I wonder if we could do it as a separate crate to prove the idea and then use that as evidence in an ACP?