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

> 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.

I'd argue that it's more than a little surprising. The assumption here is that the pull algorithm is even *aware* that there are additional concurrent read requests that it needs to respond to. I'm assuming the only way to do that is to `while(c.byobRequest !== null) {}`, but as you can see from the second issue here, `c.byobRequest` is not necessarily guaranteed to be `null` when using a default reader -- also something the pull algorithm really cannot reliably determine. At the very least this needs to be documented better but I suspect this needs to be addressed in the spec.

Specifically a couple of changes:

1. Calling `controller.enqueue(view)` should likely remove the pending pull into descriptor as a well as invalidating the current `byobRequest`
2. Calling `controller.close()` when there are pending pull intos / byob read requests should automatically resolve those reads and release them back to the reader.
3. The behavior of the `controller.byobRequest` getter needs to be revisited when `autoAllocateChunkSize` is used.

-- 
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-933746619