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

I think my preferred solution is that we don't call `us.abort()` until `us.write()` settles. Thus, `writer.abort()`'s primary goal is to flush away any queued up writes, not to abort any ongoing writes.

Right now no part of the streams API has the concept of interrupting an ongoing operation, really. If we were to introduce that, it would probably be based on cancelable promises, and apply more broadly. 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.

But for now, without cancel tokens and in general without a concept of canceling an ongoing "atomic" operation, I think it's best to treat each write as atomic, and not something that can be interrupted by abort.

What do you think?

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