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

> A minor exception I discovered:

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?

> But does this mean that the WritableStream will take another argument but passes it through to the underlying source without doing anything with it?

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.

It would be a different story if we were passing the cancel token to some operation controlled mostly or entirely by the stream implementation. For example, if we were passing a cancel token to pipeTo(), we could pass that through to any read or write calls and look at how they cooperated, but would we would also interpret a cancelation request on that token to mean "stop piping", so even if an individual write or read does not cooperate because of an uncooperative underlying sink, we could stop the pipe loop as soon as possible.

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

Received on Monday, 28 November 2016 13:14:21 UTC