fix: Shared must relinquish control to the executor if repolled #2136
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If the wrapped future requires that another future runs before it stops waking itself while returning pending the current Shared will loop forever. This removes the `REPOLL` case and returns pending immediately, since the current task is recorded and therefore woken through `Notifier`'s `wake_by_ref` the `Shared` future will still be polled again Fixes rust-lang#2130
krallin
added a commit
to krallin/futures-rs
that referenced
this pull request
May 13, 2020
…polled This backports rust-lang#2136 to Futures 0.1. There isn't much to add on top of what's mentioned in rust-lang#2136: the same bug exists in Futures 0.1, and it'll fail in the same way when polled in recent versions of Tokio (rust-lang#2418). Backporting to 0.1 allows codebases that still have some Futures 0.1 code around to still use newer versions of Tokio.
krallin
added a commit
to krallin/futures-rs
that referenced
this pull request
May 13, 2020
…polled This backports rust-lang#2136 to Futures 0.1. There isn't much to add on top of what's mentioned in rust-lang#2136: the same bug exists in Futures 0.1, and it'll fail in the same way when polled in recent versions of Tokio (rust-lang#2418). Backporting to 0.1 allows codebases that still have some Futures 0.1 code around to still use newer versions of Tokio.
krallin
added a commit
to krallin/futures-rs
that referenced
this pull request
May 23, 2020
…polled This backports rust-lang#2136 to Futures 0.1. There isn't much to add on top of what's mentioned in rust-lang#2136: the same bug exists in Futures 0.1, and it'll fail in the same way when polled in recent versions of Tokio (rust-lang#2418). Backporting to 0.1 allows codebases that still have some Futures 0.1 code around to still use newer versions of Tokio.
taiki-e
pushed a commit
that referenced
this pull request
Sep 5, 2020
…polled This backports #2136 to Futures 0.1. There isn't much to add on top of what's mentioned in #2136: the same bug exists in Futures 0.1, and it'll fail in the same way when polled in recent versions of Tokio (#2418). Backporting to 0.1 allows codebases that still have some Futures 0.1 code around to still use newer versions of Tokio.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If the wrapped future requires that another future runs before it stops
waking itself while returning pending the current Shared will loop
forever. This removes the
REPOLLcase and returns pending immediately,since the current task is recorded and therefore woken through
Notifier'swake_by_reftheSharedfuture will still be polledagain
Fixes #2130