Re: [whatwg/streams] Settle reader.[[closedPromise]] before performing close/error steps of read requests (#1102)

There *is* an alternative solution which retains the old behavior, i.e. resolving `[[closedPromise]]` **after** calling the close steps:

1. After running the close steps, `ReadableStreamClose` must *re-acquire* `stream.[[reader]]`, since the close steps could have released the lock of the current reader, and possibly even acquired a new reader.
2. `ReadableStreamClose` must first check if `reader.[[closedPromise]]` is still pending, since the close steps may have released the lock and changed it to a rejected promise. If it is not pending, it must *do nothing*, i.e. it must not replace the current promise with a resolved one.
3. In step 3 of `ReadableStreamReaderGenericRelease`, we cannot use `reader.[[stream]].[[state]]` to determine whether we can reject `[[closedPromise]]` or we need to replace it. As discussed earlier, when this is run as part of the close steps of a read request, the stream's state will already be `"closed"` but our `[[closedPromise]]` is still pending. Thus, we would need to change this step to check directly whether `[[closedPromise]]` is still pending. (This *does* align a bit closer with `WritableStreamDefaultWriterEnsureReadyPromiseRejected` though.)

But you'd still have the (kind of weird) situation where `stream.[[state]]` and `reader.[[closedPromise]]` don't agree inside the close steps of a read request... 😕

I think this alternative solution is more difficult to understand and maintain than the current solution. I still prefer the current one. 😁

-- 
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/1102#issuecomment-774720102