Skip to content

Feature request: Add biased support to join! and try_join! #7304

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
jlizen opened this issue May 4, 2025 · 4 comments · May be fixed by #7307
Open

Feature request: Add biased support to join! and try_join! #7304

jlizen opened this issue May 4, 2025 · 4 comments · May be fixed by #7307
Labels
A-tokio Area: The main tokio crate C-feature-request Category: A feature request. M-macros Module: macros in the main Tokio crate

Comments

@jlizen
Copy link
Member

jlizen commented May 4, 2025

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.

@jlizen jlizen added A-tokio Area: The main tokio crate C-feature-request Category: A feature request. labels May 4, 2025
@Darksonn Darksonn added the M-macros Module: macros in the main Tokio crate label May 4, 2025
@maminrayej
Copy link
Member

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
Copy link
Member Author

jlizen commented May 4, 2025

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
Copy link
Member Author

jlizen commented May 4, 2025

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
Copy link
Member

... whether a contribution would be accepted.

Of course.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-tokio Area: The main tokio crate C-feature-request Category: A feature request. M-macros Module: macros in the main Tokio crate
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants