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

@domenic 

> For example, us.write() and writer.write() would accept a cancel token. us.write()'s cancel token would become canceled if either the token passed to writer.write() is called, or if writer.abort() is called. Then us.write() can decide whether it wants to cancel the ongoing write (or at least the returned promise) and thus allow us.abort() to execute.

Since the `WritableStreamDefaultController` has only one active `us.write()` at a time, I agree it makes sense to use a cancel token to communicate an abort signal from the controller to the sink as just an interface between them.

Having `writer.write()` take a cancel token in addition to the value argument, and handle/pass it in the Streams API is a separate design decision. This affects not only the controller(s), but also the WritableStream's semantics.

Suppose that we have issued 3 `write()`s on a writer, w0, w1 and w2. We cancel the token for w1. I think what's expected is that:
- if the sink hasn't started processing w1,
  - finish w0
  - throw away w1, w2
  - invoke `sink.abort()`
- if the sink is processing w1,
  - cancel the token passed to the sink with w1 and wait for completion
  - (regardless of the result of w1 processing, continue to do the following)
  - throw away w2
  - invoke `sink.abort()`
- if the sink has already finished processing w1, and is now processing w2,
  - cancel the token passed to the sink with w2 and wait for completion
  - (ditto)
  - invoke `sink.abort()`

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

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