Re: [whatwg/streams] Define WritableStreamDefaultController.signal (#1132)

@ricea commented on this pull request.

We're going to need some tests.

> @@ -4252,6 +4268,10 @@ The following abstract operations operate on {{WritableStream}} instances at a h
  id="writable-stream-abort">WritableStreamAbort(|stream|, |reason|)</dfn> performs the following
  steps:
 
+ 1. If |stream|.[=WritableStream/[[state]]=] is "`closed`" or "`errored`", return
+    [=a promise resolved with=] undefined.
+ 1. [=Signal abort=] on

I believe that this won't throw an exception. @domenic can you confirm?

We need to be careful about re-entrancy here, but it looks safe to me.

> @@ -4421,7 +4441,8 @@ the {{WritableStream}}'s public API.
  1. [=Reject=] |stream|.[=WritableStream/[[inFlightCloseRequest]]=] with |error|.
  1. Set |stream|.[=WritableStream/[[inFlightCloseRequest]]=] to undefined.
  1. Assert: |stream|.[=WritableStream/[[state]]=] is "`writable`" or "`erroring`".
- 1. If |stream|.[=WritableStream/[[pendingAbortRequest]]=] is not undefined,
+ 1. If |stream|.[=WritableStream/[[pendingAbortRequest]]=] is not undefined and |error| is not an

If I understand correctly, this results in `abort()` being called after `close()` in some cases. I'm not sure that changing the guarantee that only one of `abort()` or `close()` is called is a good idea. If `close()` needs to do additional cleanup when it is aborted, it can do it itself.

As a technical issue, the `[[abortAlgorithm]]` slot is cleared before `[[closeAlgorithm]]` is executed, so as written this won't work.

-- 
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/1132#pullrequestreview-675987276