-
Notifications
You must be signed in to change notification settings - Fork 635
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
FuturesUnordered: Limit max value of yield_every #2527
Conversation
9afc0f3
to
ebf3681
Compare
Sounds very reasonable to have a constant cap on the number of polls in order to avoid quadratic behavior in Tokio (and I guess also other runtimes that implement preemption). Thanks! Crossing my fingers that it get accepted and backported. |
Is there any branch with changes backported to 0.3? I tried to use it but I couldn't make it work with tokio
I do have |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd personally make this a const
the same way it was in the pre-#2333 implementation, and include a bit more docs (you can probably copy-paste that too from the old code), but otherwise 👍 for this change.
ebf3681
to
d3747e6
Compare
Published in 0.3.19. |
@@ -340,7 +340,7 @@ fn polled_only_once_at_most_per_iteration() { | |||
|
|||
let mut tasks = FuturesUnordered::from_iter(vec![F::default(); 33]); | |||
assert!(tasks.poll_next_unpin(cx).is_pending()); | |||
assert_eq!(33, tasks.iter().filter(|f| f.polled).count()); | |||
assert_eq!(32, tasks.iter().filter(|f| f.polled).count()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this test be adjusted to ensure that eventually all of the contained futures are polled?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The purpose of the test is to make sure that the same future is not polled multiple times in a single poll_next call (#2333), so I think it's fine as is.
fn polled_only_once_at_most_per_iteration() { |
UPDATE(taiki-e): Note that this is not an approach we currently use; see #2551 for an approach we currently use.
Fixes #2526
The initial version of the #2333 did the same thing (tokio-rs/tokio#3493 (comment)), but at the time I thought it was unnecessary and removed it.
before
after
A little slower than the version using unconstrained, but a little faster than the version using tokio::spawn, on my machine.
with unconstrained
with tokio::spawn
fyi @jonhoo