Re: [whatwg/streams] Add HasBackpressure operation to ReadableStream controllers (#767)

The user-visible behaviour change is one extra microtask before the first transform() is called when starting without backpressure. I think. Counting microtask iterations is tricky. Testing the number of microtask iterations is even trickier, so I'm not going to try. We make up for the extra call to pull() at startup by avoiding unnecessary calls to pull() when a read() is in process, so on balance it works out well.

In #777 I argue for always starting with backpressure by default, which would make this difference even less consequential.

This means there isn't anything I can test here. However, thanks to your hint I noticed that calling HasBackpressure before start() has completed will always return true, so I just hardcoded that value, which then let me simplify TSDefaultSource's start() method.

When a close or error is triggered by the TransformStream itself, it always sets `_readableClosed`, which prevents reaching the call to HasBackpressure. If it gets triggered by the consumer calling cancel() than the TransformStream is notified by the source `cancel()` method before we get a chance to call HasBackpressure, setting `_readableClosed`.

As part of my work in in restructuring the TransformStream implementation, I realised that the `controller.enqueue()` method which calls HasBackpressure will be stream-type specific. So there's no need for it to be polymorphic, and I've replaced it with a ReadableStreamDefaultControllerHasBackpressure abstract operation.

The benefit of having a `controller.ready` on ReadableStream would be that custom TransformStream-alike objects could share the same logic the built-in one does. But it's not very compelling. Implementing transforms without using TransformStream is a very niche case.

-- 
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/767#issuecomment-324894093