Provide a select_biased! macro

[ifc2t]

Since #2152 introduced the select! macro, is it possible to provide a select_biased! macro as well, similar to the futures-rs one?

It's useful in cases where the polling order does matter, such as when you need to guarantee dropping a future at the next yield point.

[Darksonn]

I'm not sure adding a new macro makes sense, but we could add a @bias token or similar?

[carllerche]

I agree that there are use cases for controlling the poll order. However, I don't love the idea of having a separate macro for the use case.

I wonder if there is a way to work this into the select! macro itself. Maybe some way to annotate branches at the start as prioritized or something...

[qm3ster]

Henlo. I was having this whole experience today, and here is what I learned:
The amazing and superior tokio::select! macro actually runs in order, it just selects a starting point with some kind of vendored pseudorandom generator, as follows:

let start = $crate::macros::support::thread_rng_n(BRANCHES);

for i in 0..BRANCHES {
    let branch;
    #[allow(clippy::modulo_one)]
    {
        branch = (start + i) % BRANCHES;
    }

I propose that we move all of the current implementation into a (possibly public? maybe later?) select_starting_at! macro that takes an additional expression to initialize start.

From there, we can reimplement select! to call that with $crate::macros::support::thread_rng_n(BRANCHES); and add select_biased! that just uses 0, thus achieving complete code reuse.

Regarding special annotations on the arms, the current for-based design already doesn't allow patterns like "poll A then C then B then D", so for "always poll A first, then B,C,D in random order" it would have to be changed completely.

Declaration order is a well-understood pattern, and crazy patterns can be achieved with nested selects, if desirable.