Re: [whatwg/streams] Support teeing readable byte streams (#1114)

@domenic commented on this pull request.



> @@ -3205,7 +3442,7 @@ The following abstract operations support the implementation of the
  1. Let |firstDescriptor| be |controller|.[=ReadableByteStreamController/[[pendingPullIntos]]=][0].
  1. If |firstDescriptor|'s [=pull-into descriptor/byte offset=] + |firstDescriptor|' [=pull-into
     descriptor/bytes filled=] is not |view|.\[[ByteOffset]], throw a {{RangeError}} exception.
- 1. If |firstDescriptor|'s [=pull-into descriptor/byte length=] is not |view|.\[[ByteLength]], throw
+ 1. If |firstDescriptor|'s [=pull-into descriptor/byte length=] < |view|.\[[ByteLength]], throw

Sorry for missing this. Doing this in the same PR makes sense, but I'm wondering if maybe we had a reason for this in the first place...

In particular, consider a consumer which wants to allocate and use, say, 1 MiB of memory. It allocates a 1 MiB buffer, and passes it through the stream, and gets it back, round and round.

My understanding is that in the current spec, no matter what, they will always get back a 1 MiB buffer. Even if the underlying byte source calls `byobRequest.respond(5)`, the returned buffer will still be 1 MiB (even if the _view_ is only 5 bytes). So when they cycle that buffer into another `reader.read(newViewOntoSameBuffer)` call, they can get up to 1 MiB that next time.

Whereas, if we allow smaller results to be sent back from `respondWithNewView()`, then the consumer would lose their 1 MiB buffer forever, and only get back a 5 byte buffer in return.

Now, that said, having written that up, it seems like we could still allow smaller views onto larger buffers. I.e. we could change the check from checking the view size to checking the buffer size. But I think we probably don't want to allow respondWithNewView() to take arbitrarily-small buffers?

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

Received on Thursday, 25 March 2021 22:40:18 UTC