Re: [whatwg/streams] Possible spec bug with concurrent byob reads (#1170)

The specification expects that you *first* close the stream, and *then* commit the BYOB request. Something like:
```javascript
// respond to first read with some data
c.byobRequest.respond(10);

// respond to second read by closing the stream
c.close();
c.byobRequest.respond(0);
```
The last `respond(0)` is necessary because we need to return control of the BYOB view back to the reader.

I agree that this behavior can be a little bit surprising. After all, you didn't even *access* the second BYOB request, so there's no way you could have modified or detached its view. 

Maybe the specification could be a little bit smarter? If `controller.[[byobRequest]]` is still `null` when calling `ReadableByteStreamControllerClose()`, then we *definitely* know that the BYOB view hasn't been touched yet. So it's safe for us to automatically commit it, and return the view back to the reader.

Keep in mind that, if you *do* access `controller.byobRequest` first, you still have to explicitly respond to it:
```javascript
const byobRequest = c.byobRequest;
c.close();
byobRequest.respond(0); // still required
```

-- 
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/issues/1170#issuecomment-933674328