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

> Is this the same as what you had in your mind?

That wasn't quite what I had in mind. Cancel tokens would only be used to control a single write() instance, and wouldn't change the state of the stream. You'd do that separately by calling `writer.abort()`. So:

- If the sink hasn't started processing w1
  - Finish w0
  - Throw away w1; return a "canceled promise" from that write() (rejected with a `Cancel` instance; [more details](https://github.com/tc39/proposal-cancelable-promises/blob/master/Not%20an%20Error.md))
  - Start w2
- If the sink is processing w1
  - cancel the token passed to the sink with w1 and wait for completion. Return a promise corresponding to what the sink returns (so it might be fulfilled or rejected, if the cancelation didn't work, or it might be canceled, if it did).
  - Start w2
- If the sink has already finished processing w1, and is now processing w2,
  - Start w2; ignore the cancelation request

---

I'm glad everyone seems on board with making `us.write()` and `us.close()` non-interruptible. I think that is a good simplification, despite the temporary loss in functionality.

> I spoke with @tyoshino in person and here is the plan we came up with:

This plan sounds good to me, but I am interested in exploring a shutdown/destroy/finally underlying sink API. Maybe we should wait until the dust settles and see how bad things are after resolving this issue and #620 before deciding if that is necessary.

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