Implement flow-control in TransformStream fixes #330 maybe #429
Conversation
Promise-ify the TransformStream so that it always waits for both a write() and a pull() to have happened, returning a Promise in both cases so that callers can know when it's safe to call again. Previously pull() had no effect and the TransformStream was strictly pumped by its write() callers.
|
It appears I did make a bad assumption about pull() being called whenever the previous pull() promise resolves. If the transformation function is something cool like a filtering function that does not always enqueue a result, then RequestReadableStreamPull as invoked by ReadFromReadableStreamReader will not reissue the pull, breaking stream flow. I suspect reissuing the pull may make infinite loops quite likely, suggesting my patch here that tries to be clever with Promise pairing is not the way. I think I better understand the discussion on #330 now and will look into using I'm going to leave this PR open for now since I have a test and am about to push my follow-up test that demonstrates why my current PR is no good and plan to try and provide a better patch tomorrow. But I won't take offense if you close this until I have something that works! :) |
|
Going to close this in preparation for a transform stream overhaul :) |
Promise-ify the TransformStream so that it always waits for both a
write() and a pull() to have happened, returning a Promise in both
cases so that callers can know when it's safe to call again.
Previously pull() had no effect and the TransformStream was strictly
pumped by its write() callers.
NB: I may be making a dangerous assumption about pull() always being called. I will endeavor to better come up-to-speed on the spec and reference implementation and investigate this on my own in the next ~1 week. But in the meantime, I figured I'd put this here since it does pass the existing tests and the test I added that's only slightly pyramid-of-doomy.