Re: [whatwg/streams] Release reader immediately when shutting down a pipe (PR #1208)

> This does have the side effect of releasing the reader _before_ the pipe promise resolves. I don't know if this is acceptable.

Hmm, this means that the pipe could still cancel the readable *after* it has released its reader lock but *before* it settles the pipe promise. That might be quite unexpected: the user might have already acquired a new reader, and only that *new reader* should have the ability to cancel the stream.

Possible solutions:
1. We could try to split up `ReadableStream(Default|BYOB)Release`, such that the read requests are already rejected *but* the reader is still locked to the stream. We would then *actually* release the reader as part of the "finalize" steps (as in the current spec).
2. We could make the pipe releases its reader, and immediately acquire a new reader. It would no longer use that reader to request new chunks (since *shuttingDown* is already true), it would only be used to keep the stream locked (in case we still want to cancel it).

Option 2 is probably the easiest to implement, but it may require a note to explain why this weird "release + acquire" dance is necessary. Then again, we already mention that:
> the exact manner in which this happens is not observable to author code, and so there is flexibility in how this is done

so user agents are free to implement these steps differently if they want. 🤷‍♂️ 

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/pull/1208#issuecomment-1013838712

You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/streams/pull/1208/c1013838712@github.com>