-
Notifications
You must be signed in to change notification settings - Fork 161
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Don't exert backpressure after the first push.
Before this commit, BaseReadableStream would immediately exert backpressure (i.e. return `false` from `push`), even if the buffer was empty at the time of being pushed into. After it, backpressure will only be exerted if the buffer is nonempty. This sets the stage for (I think) solving #24, since before this commit, it was impossible for a BaseReadableStream to ever return `true` from `push`. After it, that is possible, as long as the stream clears its internal buffer as fast as it can.
- Loading branch information
Showing
3 changed files
with
42 additions
and
2 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
6e2a21d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks fine to me that we forward written data to the pipe destination when piping. I'm just a bit worried about possible stack growth on long chain of pipes.
But the new line shouldn't this be like this?
If
this.[[buffer]]
is empty, return trueOtherwise, return false
I know that this doesn't make sense inside the current BaseReadableStream algorithm definition but I think what you're trying to do is conceptually equivalent to this.
Not only
this.[[buffer]]
but alsothis.[[pulling]]
,this.[[state]]
andthis.[[waitPromise]]
should be (and are actually in your updated reference impl.) updated after investigating howdata
has been processed (e.g. by checking emptiness ofthis.[[buffer]]
). For non-piping case, the processing is just "pushdata
ontothis.[[buffer]]
". If not, it's forwarding logic you're just prototyping.6e2a21d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tyoshino it seems like you're referring to the entire series of commits, and not just this one?
I think this is taken care of by 7ce96fb#diff-89532e378d4091617b906f870b427524R106 , which prevents reetrancy into the
pull
method, which was the potentially-recursive method I found. I am not sure I fully grasp the danger you're referring to though.I guess you are essentially proposing replacing "waiting vs. readable" with "empty vs. nonempty buffer" in the if statements? I can't really see a way to change the wording to make this work. E.g. by the time you want to return from the function the buffer will always be nonempty.
Indeed, I haven't updated the spec to reflect the last commit yet. Before merging I certainly will do so. I kind of want to investigate a variety of fixes for this large issue first.
Thanks for your thoughts!
6e2a21d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but I might have missed some points. Sorry about that.
Oh, I overlooked it. Got it.
It seems I should re-read whole commits you made.
OK. Thanks!