Feature request: Add `biased` support to `join!` and `try_join!`

[jlizen]

Is your feature request related to a problem? Please describe.
I have two long-running futures that I need to drive locally in a task.

Specifically, the futures are a AWS Lambda function handler listener, and secondary event listener that does some extra cleanup operations after the main event processing is complete. Something along these lines.

Normally I would reach for join! or try_join! for this. However, I don't actually want to rotate which future I poll first. I want to always poll my primary server if it is ready to make progress, over the 'cleanup' event listener. Context here is that an AWS Lambda only receives one request a time per node.

Instead, I want to invoke join! or try_join! in a way that always polls sequentially based on the order of futures in the macro body.

Describe the solution you'd like
Tokio added biased support to select! some time back - #2181

It would be great to have the same API for join! or try_join!

Describe alternatives you've considered
You can accomplish the same thing using select! in a loop, and select! does support biased.

This gets very verbose though since you need to explicitly continue polling subsequent futures after one of them finishes. join! and try_join! are much friendlier APIs for this use case.

[maminrayej]

Adding biased; makes sense, but note that Tokio does not randomize among futures passed to join! and try_join!. It rotates which future is polled first, so for example if you have three futures, they will be polled like:

(f1, f2, f3) -> (f2, f3, f1) -> (f3, f1, f2) -> (f1, f2, f3) -> ...

adding biased; would effectively remove the rotation and keep the order as (f1, f2, f3).

[jlizen]

Tokio does not randomize among futures passed to join! and try_join!. It rotates which future is polled first

Thanks for the clarification! Yes, I am interested in always polling in the order they are passed in, rather than cycling which is polled first per wake.

[jlizen]

Oh, I didn't state it explicitly, but I'm open to doing the implementation work for this - sharing for feedback though on whether a contribution would be accepted.

[maminrayej]

... whether a contribution would be accepted.

Of course.