-
Notifications
You must be signed in to change notification settings - Fork 162
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
Resolve BYOB reads immediately on cancel #1129
Merged
domenic
merged 4 commits into
whatwg:main
from
MattiasBuelens:resolve-byob-reads-on-cancel
Jun 2, 2021
Merged
Resolve BYOB reads immediately on cancel #1129
domenic
merged 4 commits into
whatwg:main
from
MattiasBuelens:resolve-byob-reads-on-cancel
Jun 2, 2021
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
I initially thought that we'd need to refactor large parts of the specification to make this work, but surprisingly there aren't that many changes needed. So that's good... assuming I didn't miss anything important. 😅 |
ricea
approved these changes
May 27, 2021
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.
lgtm
domenic
pushed a commit
to web-platform-tests/wpt
that referenced
this pull request
Jun 1, 2021
See whatwg/streams#1129 for the accompanying spec change.
5 tasks
moz-v2v-gh
pushed a commit
to mozilla/gecko-dev
that referenced
this pull request
Jun 8, 2021
…on cancel, a=testonly Automatic update from web-platform-tests Streams: resolve BYOB reads immediately on cancel See whatwg/streams#1129 for the accompanying spec change. -- wpt-commits: b869e60df1b8d3840e09b41c5e987c7e23f6856c wpt-pr: 29128
jamienicol
pushed a commit
to jamienicol/gecko
that referenced
this pull request
Jun 9, 2021
…on cancel, a=testonly Automatic update from web-platform-tests Streams: resolve BYOB reads immediately on cancel See whatwg/streams#1129 for the accompanying spec change. -- wpt-commits: b869e60df1b8d3840e09b41c5e987c7e23f6856c wpt-pr: 29128
blueboxd
pushed a commit
to blueboxd/chromium-legacy
that referenced
this pull request
Oct 13, 2021
This CL is based on spec changes made in whatwg/streams#1129. Summary/context of changes: If you cancel a stream while a BYOB read is pending, the stream should simply not give back the buffer. This means that cancel() can immediately resolve all pending BYOB reads with the classic { done: true, value: undefined }, without having to wait for the underlying byte source. Also, when the stream is cancelled, any pending BYOB request is now immediately invalidated, so the underlying byte source doesn't erroneously think that it still needs to provide a response. Bug: 1223565 Change-Id: I17d1d5cfaee80c02c51bc682447b381ade4363bf Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3216778 Commit-Queue: Nidhi Jaju <nidhijaju@chromium.org> Reviewed-by: Adam Rice <ricea@chromium.org> Cr-Commit-Position: refs/heads/main@{#930987}
mjfroman
pushed a commit
to mjfroman/moz-libwebrtc-third-party
that referenced
this pull request
Oct 14, 2022
This CL is based on spec changes made in whatwg/streams#1129. Summary/context of changes: If you cancel a stream while a BYOB read is pending, the stream should simply not give back the buffer. This means that cancel() can immediately resolve all pending BYOB reads with the classic { done: true, value: undefined }, without having to wait for the underlying byte source. Also, when the stream is cancelled, any pending BYOB request is now immediately invalidated, so the underlying byte source doesn't erroneously think that it still needs to provide a response. Bug: 1223565 Change-Id: I17d1d5cfaee80c02c51bc682447b381ade4363bf Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3216778 Commit-Queue: Nidhi Jaju <nidhijaju@chromium.org> Reviewed-by: Adam Rice <ricea@chromium.org> Cr-Commit-Position: refs/heads/main@{#930987} NOKEYCHECK=True GitOrigin-RevId: e8c4592de3851305dd1f3a021d528c84f8d98658
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.
Right now, if you cancel the stream while a BYOB read is pending, the stream has to wait for the underlying byte source to call
respond(0)
before it can return the BYOB request's buffer to the caller. Effectively, every single underlying byte source would need to look like this:This is a footgun: we have to rely on the underlying byte source to do this correctly. We are unable to do this automatically, since we don't know if or how the source might be using the BYOB request (for example, it might have transferred the buffer). If the source fails to call
respond(0)
, then the BYOB read never resolves and the reader gets stuck. If you forget to implementcancel()
altogether, then the default implementation will not help either, since it is specified to do nothing.In #1114 (comment) and #1123 (comment), @domenic suggested that if you cancel the stream while a BYOB read is pending, the stream should simply not give you back your buffer. This means that
cancel()
can immediately resolve all pending BYOB reads with the classic{ done: true, value: undefined }
, without having to wait for the underlying byte source. This solves the problem, and would make it easier to implement an underlying byte source.This PR implements this suggestion. To make it work, I also had to change one other thing: when the stream is cancelled, any pending BYOB request is now immediately invalidated, so the underlying byte source doesn't erroneously think that it still needs to provide a response. (This aligns with the behavior of
controller.enqueue()
, which throws if the stream is already closed.)(See WHATWG Working Mode: Changes for more details.)
Preview | Diff