- From: Mattias Buelens <notifications@github.com>
- Date: Mon, 19 Jul 2021 16:20:00 -0700
- To: whatwg/streams <streams@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/streams/pull/1145/review/710054868@github.com>
@MattiasBuelens commented on this pull request. > @@ -1570,6 +1595,10 @@ function ReadableByteStreamControllerRespondInReadableState(controller, bytesWri return; } + if (pullIntoDescriptor.readFully && pullIntoDescriptor.bytesFilled < pullIntoDescriptor.byteLength) { + return; There are two places where the magic happens: * Here, in `ReadableByteStreamControllerRespondInReadableState`, we make sure not to shift the first pull-into descriptor if a call to `respond()` or `respondWithNewView()` did not fill the entire view. * [Over in `ReadableByteStreamControllerFillPullIntoDescriptorFromQueue`](https://github.com/whatwg/streams/commit/383c9e543a63938a2c2497a627b0a216d89e7250#diff-db46b8b33e26be52c078fa1540a3516fca7f75af6effb18e9b152efbd114b4bfL1350-R1370), we make sure to indicate that the pull-into descriptor is "not ready" if the total queue size is smaller than the view's length. This is used by the callers to decide if the pull-into descriptor should be shifted out or not. This handles the case where there were already some chunks queued up before `readFully()` was called, or if the underlying source uses `enqueue()` to (partially) fill up the pull-into descriptor. I'll try to explain all of this in a code comment. 🙂 -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/whatwg/streams/pull/1145#discussion_r672694353
Received on Monday, 19 July 2021 23:20:13 UTC