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

Coming from the Node.js perspective, it would be better for the `AbortController` to be associated with the `Reader` as a whole rather than the individual read operation. So...

```js
const controller = new AbortController();

// Assume "rs" contains chunks A and B.
const reader = rs.getReader({ signal: controller.signal });

const promise1 = reader.read();
const promise2 = reader.read();
const promise3 = reader.read();

controller.abort();
```

There are a couple reasons for this... 

1. Not all read operations are cancelable. libuv fs operations, for instance, cannot be canceled once they are picked up by the libuv thread pool. You can only cancel them while they are still queued. If we consider each discreet read a single libuv request, then, the read-level abort is of limited use and unreliable. 

2. In most operations, it's the entire sequence of reads that are critical. It will be rare to abort a single read. What we'd want is to abort the entire set of read operations and clean up the underlying resource.

When the abort() is called, I would expect any already fulfilled reads to just ignore it but all subsequent still pending read promises to be rejected. So, for the sake of the example, let's assume that promise1 ends up resolving synchronously (for whatever reason) but promise2 and promise3 are still pending. Both promise2 and promise3 would reject with `AbortError`.

I really cannot think of a case where I would want to abort a single read without aborting the entire subsequent sequence of reads that also may be pending.

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