- From: Mattias Buelens <notifications@github.com>
- Date: Thu, 27 Jan 2022 13:08:59 -0800
- To: whatwg/streams <streams@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/streams/pull/1208/review/865430270@github.com>
@MattiasBuelens commented on this pull request.
> @@ -475,6 +483,20 @@ function WritableStreamDefaultWriterGetDesiredSize(writer) {
return WritableStreamDefaultControllerGetDesiredSize(stream._controller);
}
+function WritableStreamDefaultWriterIsOrBecomesErrored(writer, errorListener) {
Coming back to this:
> Adding `await flushAsyncEvents()` before calling `pipeTo()` in that test restores the order and fixes the problem. Good enough? 🤷♂️
It seems the main difference is that, when you call `readable.cancel()`, we *always* synchronously call `source.cancel()` regardless of whether `source.start()` has already settled. On the other hand, when you call `writable.abort()`, we first wait for `sink.start()` to settle before we call `sink.abort()`.
IIRC the reason for this difference is so you can do e.g. an async loop in `source.start()`:
```javascript
new ReadableStream({
async start(c) {
for (let i = 0; i < 10; i++) {
await new Promise(r => setTimeout(r, 1000));
c.enqueue("chunk");
}
c.close();
}
})
```
whereas for `sink.start()` this doesn't make sense.
I guess, if we *really* wanted to, we could have the test check when `writableController.signal` becomes aborted? That should happen synchronously *regardless* of whether `sink.start()` has already settled.
--
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/pull/1208#discussion_r794000293
You are receiving this because you are subscribed to this thread.
Message ID: <whatwg/streams/pull/1208/review/865430270@github.com>
Received on Thursday, 27 January 2022 21:09:12 UTC