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

> * What does this do to `promise2`? Probably reject it with an `"AbortError"` `DOMException` (like in other `AbortSignal` scenarios).

Yes, that seems most appropriate. We do the same for `rs.pipeTo(dest, { signal })`.

While we're on the topic: I think `rs.pipeTo(dest, { signal })` should also use the given signal for all of its read requests. That will allow the pipe to shutdown faster.

> * What happens if abort is signaled after the read request is already fulfilled? Probably nothing (like in other `AbortSignal` scenarios).

Yup, that makes sense.

I think it's also important to guarantee that if we *do* reject the read request with an `AbortError`, then the next read request *will* receive the "missed" chunk. That is, aborting any read request does not "lose" any chunks. (We should have some tests for this.)

> * Does this do more than just dequeue the read request? For example, could it be communicated all the way down to the underlying source, I guess via `pull()`? I don't think this helps much, but it's worth checking...

I think just dequeuing the read request is fine.

[A while back, I suggested](https://github.com/whatwg/streams/issues/1014#issuecomment-531244783) we could pass an `AbortSignal` to `pull()`, but that was tied to `rs.cancel()`. Not sure where we want to go with that. 🤷 

---

Could we also make this work for BYOB readers? We'd probably want something like `reader.read(view, { signal })`, but this has some problems:

* We need to return ownership of the backing array buffer after the read is aborted, but we can't do that if we merely reject with an `AbortError`.
* Before we can return ownership of the buffer, we need to take it away from any pending `byobRequest`. But how will we know when the underlying sink is done using `byobRequest.view`?

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