- From: Domenic Denicola <notifications@github.com>
- Date: Wed, 31 Mar 2021 15:26:01 -0700
- To: whatwg/streams <streams@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/streams/pull/1114/review/625766982@github.com>
@domenic commented on this pull request. > + if (forBranch2 === true) { + if (canceled1 === false) { + const clonedChunk = CloneArrayBufferView(chunk); + ReadableByteStreamControllerEnqueue(branch1._controller, clonedChunk); + } + if (canceled2 === true) { + chunk = new Uint8Array(chunk.buffer, chunk.byteOffset, 0); + } + ReadableByteStreamControllerRespondWithNewView(branch2._controller, chunk); + } else { + if (canceled2 === false) { + const clonedChunk = CloneArrayBufferView(chunk); + ReadableByteStreamControllerEnqueue(branch2._controller, clonedChunk); + } + if (canceled1 === true) { + chunk = new Uint8Array(chunk.buffer, chunk.byteOffset, 0); > That might work, but it can cause unexpected behavior: Eh, seems OK. Your fault for not returning the promise to signal you were still planning to use `byobRequest`. > This would break the readInto() example. The BYOB reader needs to get its buffer back. Well, the readInto() example doesn't cancel the stream. I guess maybe that's my suggestion (and perhaps even the current intent of the spec): if you cancel the stream with a BYOB request pending, you don't expect to get your buffer back. You should have waited to cancel until the outstanding BYOB request completed. How bad would that be? -- 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/1114#discussion_r605259271
Received on Wednesday, 31 March 2021 22:26:19 UTC