Open jedwards1211 opened 1 year ago
I suppose it would be more accurate to say that stream.cancel()
behaves like const reader = stream.getReader(); reader.cancel(); reader.releaseLock()
, where reader
is a temporary reader. But that still wouldn't be a good explanation.
In essence, you use stream.cancel()
to cancel a stream if you haven't locked it. If you have, you should use reader.cancel()
instead, which requires that your reader
still has the active lock on the stream.
I know it's a non-normative comment, but what https://streams.spec.whatwg.org/#default-reader-prototype says threw me for a loop:
Because
stream.cancel()
rejects if the stream is locked, I incorrectly assumed I would need toHowever,
reader.cancel()
does reject if the lock has been released; reading the spec, I see thatreader.cancel()
actually doesn't throw if the stream is locked, unlikestream.cancel()
, so the two don't behave the same at all.It would be closer to the truth to say
reader.cancel([ reason ])
behaves likereader.releaseLock()
followed bystream.cancel(reason)
, since that wouldn't reject; but, even this is inaccurate, since according to the specreader.cancel
doesn't release the lock, it just bypasses theIsReadableStreamLocked
check altogether.