-
Notifications
You must be signed in to change notification settings - Fork 628
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: Respect yielding from future #2551
Conversation
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.
This seems good to me.
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'm okay with the change as-is, but see my one concern around over-eager yielding.
// avoid starving other tasks waiting on the executor. | ||
// (polling the same future twice per iteration may cause | ||
// the problem: https://github.com/rust-lang/futures-rs/pull/2333) | ||
if yielded || polled == len { |
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 worry a little about this being too eager to yield. We're saying here that if any future is awoken while we're polling it (even if it's due to something else legitimately waking it) then we're going to yield from the entire FuturesUnordered
. I wonder if it makes more sense to require observing, say, two such yields before concluding we should yield? That buffers us slightly against yielding unnecessarily while still making us yield fairly quickly when everything inside of us will yield going forward.
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 adopted this heuristic (FuturesUnordered needs to support no-std, which cannot use thread ID). Thanks for the suggestion.
Another possible implementation would be to check if the thread ID in the waker is equal to the thread currently polling the |
Any updates on this? |
Co-authored-by: Jon Gjengset <jon@thesquareplanet.com>
3002f79
to
8136c37
Compare
8136c37
to
b6afb23
Compare
Co-authored-by: Jon Gjengset <jon@thesquareplanet.com>
Co-authored-by: Jon Gjengset <jon@thesquareplanet.com>
Published in 0.3.20. |
If the future yields,
FuturesUnordered
respects it and yields too.In this patch, if the future waken before it finishes polling, we assume the future yields.
This is the approach suggested by @carllerche in discord (if I understand correctly).
And I noticed that stjepang had also suggested this approach before: rust-lang/rust#74335 (comment)
cc @cramertj @jonhoo
cc #2053
The following is a result of an example in #2526 with the addition of a counter for the number of times the futures were polled.
code
before:
after: