Re: [whatwg/streams] Note about underlyingSink close() method is misleading (#617)

> Getting into fine details, .closed will reject before .ready if there is no write pending, but will reject after .ready otherwise. Maybe we should change it to always reject after .ready?

That sounds like a good idea to me.

> I've become confused now. Is writer.abort() going to cancel an ongoing write? Or if you want "abort ASAP" semantics will you have to keep cancel tokens for all unfulfilled write() calls and loop through them after calling writer.abort()?

The latter was my thinking initially, but when you put it that way, it sounds rather unattractive. I guess we can hand `us.write()` a cancel token that is the result of "racing" an internal cancel token, which is tied to `writer.abort()`, plus the cancel token passed to `writer.write()`. That way calling `writer.abort()` will send a cancelation request to any ongoing `us.write()` even if nobody does from the outside.

-- 
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/617#issuecomment-263482506