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

> I think this is fine, given the semantics of writer.ready as an indicator of what the producer should do next. We're going for non-interruptible, not un-observable. Do you all agree?

This wasn't what I initially though the behaviour should be. But when I saw that `close()` worked that way, I decided it made sense. `.ready` is "can I write now without blocking?". `.ready` being unresolved implies that you may be able to write without blocking at some time in the future. `.ready` begin rejected means you'll never be able to use this Writer to write again. New calls to `write()` will also reject at this point, so it is consistent.

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`?

> Yeah. The thing about cancel tokens is that they represent cooperative cancelation for a given operation. So the stream implementation needs to know if the underlying sink cooperated with the cancelation or not, before it changes any of its state. It does that by looking at the return values of the underlying sink's methods---did they return a canceled promise, or no? If no, then they did not cooperate with the cancelation request, so we should ignore it.

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()`?

-- 
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-263452692