Re: [whatwg/streams] WritableStream abort logic clean up (#655)

I'd like to summarize the current (or new for some places where I made change) state transition rule of the WritableStream. There're some Qs I'd like to discuss.

- Until a WS starts, no write request becomes "a pending write"
- Once a WS starts, the head write request may picked to be a pending write if allowed by the backpressure, etc.
  - Q: Is this "one pending write at a time" restriction a part of WritableStream's semantics or WritableStreamDefaultController's semantics?
- `writer.closed` change is delayed if there's any pending write or pending close until the pending write/close finishes
- `writer.ready` gets updated immediately in response to `controller.error()` and `writer.abort()`
- `controller.error()` call made during there's pending abort wins the abort.
  - `writer.abort()` gets rejected with the error given to the `controller.error()`
  - Q: Do you like this new behavior?
- `writer.write()` gets rejected with different reasons before and after completion of sink write rejection
  - That is, for example, if we call `writer.abort()` and then `writer.writer()` when there's one pending `writer.write()` and two `writer.write()`s in `_writeRequests` and then the pending `writer.write()` finishes by rejection of sink write, the two `writer.write()`s in `_writeRequests` get rejected with the result of sink write while the `writer.write()` after `writer.abort()` gets rejected with `new TypeError('Aborted')`

Implementation notes
- For logic simplicity, state processing e.g. calculation of `readyPromiseIsPending` is done at some early timing before the method starts modifying the state variables even if it increases the code size.
- Steps in the WSFinish(?:Pending)?(Close|Write) methods are ordered so that it's easy to compare them to make it easier to find missing operation.


-- 
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/pull/655#issuecomment-272812907

Received on Monday, 16 January 2017 09:34:19 UTC