Re: [whatwg/streams] Make read requests abortable (#1103)

[From #1168](https://github.com/whatwg/streams/pull/1168#issuecomment-932756142), it turns out `rs.pipeTo(ws)` is actually cheating. To correctly express the desired behavior when `preventCancel = true`, we may in fact need abortable reads *ourselves*. 😅 

> Figure out whether the use cases on hand, and any others we can think of, are better served by invalidating individual reads vs. `abortPendingRequestsAndReleaseLock()`.

For the use case of `pipeTo()`, we don't *really* need an `AbortSignal` for each `reader.read()` call, a single signal associated with the entire reader would also suffice.

> Figure out byte stream integration.

All `read(view)` calls reject with an error, so they don't get their BYOB view back. (This is similar to `cancel()`, except that resolves pending reads with `{ done: true, value: undefined }` instead.)

The BYOB request should remain valid, so the underlying byte source can continue writing into it. However, it's no longer associated with a pending read-into request, which makes things trickier. Right now, the specification assumes that the first pull-into descriptor corresponds to the first read-into request, but this change would break this assumption.

Instead, we want committing this "detached" BYOB request to behave more like calling `controller.enqueue()`: copying bytes into any non-detached pull-into descriptors (and resolving `read(view)` requests), and putting the remaining bytes into the stream's queue.

...Sounds like a lot of spec refactoring to be done. 😛

-- 
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/1103#issuecomment-932763919