- From: Mattias Buelens <notifications@github.com>
- Date: Thu, 27 Jan 2022 13:00:07 -0800
- To: whatwg/streams <streams@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/streams/pull/1208/review/865422512@github.com>
@MattiasBuelens commented on this pull request. > @@ -475,6 +483,20 @@ function WritableStreamDefaultWriterGetDesiredSize(writer) { return WritableStreamDefaultControllerGetDesiredSize(stream._controller); } +function WritableStreamDefaultWriterIsOrBecomesErrored(writer, errorListener) { > I suspect most of the testable constraints we're imposing are in cases where the web developer controls one or both ends of the pipe, right? I'm not sure those are the ones we were planning to feasibly optimize, so starting to constrain them still seems like the right thing to do to me. But I might be missing something so please let me know. Correct. Streams created by the user agent will use [the exported algorithms](https://streams.spec.whatwg.org/#other-specs), and I think it's safe to assume that those will be called in a separate task, outside of web author code. > On the larger problem, the root of the issue seems to be how imprecise "[[state]] is or becomes" is. Does that mean: (1) synchronously after the algorithm step which sets [[state]], probably interrupting other streams-implementation code; (2) synchronously after any streams-implementation code runs; (3) synchronously after any browser code runs; (4) asynchronously is OK to some degree? (2) may be ill-specified, since there are cases where streams code calls into author code, which can then call back into streams code. We've even had cases in the past where streams code calls back *into itself*, e.g. #1172. I still prefer (1), and that's what I've been implementing. Yes, we need to be very careful when speccing, but at least any problems that arise can be fixed *within the streams implementation*. > My preference would be that, if we decide to constrain all observable behavior, we have both variants of the test, with the version without flushAsyncEvents() having the assert for the other order. That seems reasonable. 👍 -- Reply to this email directly or view it on GitHub: https://github.com/whatwg/streams/pull/1208#discussion_r793994777 You are receiving this because you are subscribed to this thread. Message ID: <whatwg/streams/pull/1208/review/865422512@github.com>
Received on Thursday, 27 January 2022 21:00:20 UTC