Re: [whatwg/streams] Various fixes for readable byte streams (#1123)

> Right, OK, this is coming back to me now. So I guess the question is whether we want to support this use case. In particular, it seems like an underlying source that closes a stream without first returning the pending BYOB request is doing the wrong thing. Allowing it to do the wrong thing but then return the buffer by doing `view.subarray(0, 0)` doesn't seem that useful?

The problem with that is we currently also *disallow* responding with 0 bytes written when still in the *readable* state. So it's not possible to do `respond(0); close();`, you *have* to do `close(); respond(0);`. If you also transferred the buffer, the equivalent of that would be to use `close(); respondWithNewView(transferredView.subarray(0, 0));`

One alternative would be to have a separate `closeWithNewView(transferredView);` method to do both at the same time. But then again, `close(); respondWithNewView(emptyTransferredView);` already does the trick. So unless there is a considerable benefit to this (some sort of optimization that is impossible with close+respond), I don't think it's worth adding a new API for this.

> From the other direction, if a stream consumer wants to cancel the stream (thus closing it), do they really expect to get their buffer back? It seems like annoying boilerplate to require that underlying source authors intercept cancels and send back the buffer. I'm inclined to just say that if you cancel the stream, you won't get your buffer back.

Right, we started the discussion in [#1114 (comment)](https://github.com/whatwg/streams/pull/1114#discussion_r605259271). The idea was that if you cancel the stream, then we *immediately* fulfill the pending read-into requests with `{ done: true, value: undefined }` and we don't bother waiting for the underlying byte source to give us those buffers back.

I'm not opposed to the idea. We'd have to refactor the specification some more though, so I'd probably want to do it in a separate PR (since this one is already quite big).

> For example, the stream was handed some data from a non-BYOB API, or had some queued up because backpressure hadn't fully propagated, or whatever. In that case, respondWithNewView() can be used to say "I know you handed me a buffer, but instead of copying into that and wasting everyone's time, let me just give you a new one".

We already have `ReadableByteStreamController.enqueue()` for this exact case. That will put the new data into the queue, and then try to fill up any pull-into requests by copying data from the queue. 😉

The way I understand it, `respondWithNewView()`'s sole purpose is to allow the underlying byte source to respond with a transferred version of the BYOB request's buffer. For all other use cases, there's `respond()` (if you didn't transfer) or `enqueue()` (if you didn't use the BYOB request at all).

-- 
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/1123#issuecomment-841511098