-
Notifications
You must be signed in to change notification settings - Fork 29.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
stream: Fix readableState.awaitDrain mechanism #6023
Conversation
138b59d
to
4b07c8f
Compare
src.listenerCount('data') === 1 && | ||
// => Check whether `dest` is still a piping destination. | ||
if (((state.pipesCount === 1 && state.pipes === dest) || | ||
(state.pipesCount > 1 && state.pipes.includes(dest))) && |
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.
Isn't .includes()
for strings and not arrays? If I'm right, that means the included test isn't failing like it should?
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’s from ES2016, but it does what you think it does, i.e. [1, 2, 3].includes(2) === true
. I like the clarity of it, but if you’d rather stick with .indexOf(…)
, I’d definitely understand that.
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.
I think we'd need .indexOf()
if we're backporting to v4.x/v5.x anyway.
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.
@mscdex You’re right, sorry. Updated this PR with indexOf
.
In 6899094 (nodejs#2325), the conditions for increasing `readableState.awaitDrain` when writing to a piping destination returns false were changed so that they could not actually be met, effectively leaving `readableState.awaitDrain` with a constant value of 0. This patch changes the conditions to testing whether the stream for which `.write()` returned false is still a piping destination, which was likely the intention of the original patch. Fixes: nodejs#5820
4b07c8f
to
21f7246
Compare
LGTM. CI once more: https://ci.nodejs.org/job/node-test-pull-request/2142/ |
CI failure looks unrelated. |
LGTM |
LGTM |
In 6899094 (#2325), the conditions for increasing `readableState.awaitDrain` when writing to a piping destination returns false were changed so that they could not actually be met, effectively leaving `readableState.awaitDrain` with a constant value of 0. This patch changes the conditions to testing whether the stream for which `.write()` returned false is still a piping destination, which was likely the intention of the original patch. Fixes: #5820 Fixes: #5257 PR-URL: #6023 Reviewed-By: Brian White <mscdex@mscdex.net> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Landed in 819b2d3 |
In 6899094 (#2325), the conditions for increasing `readableState.awaitDrain` when writing to a piping destination returns false were changed so that they could not actually be met, effectively leaving `readableState.awaitDrain` with a constant value of 0. This patch changes the conditions to testing whether the stream for which `.write()` returned false is still a piping destination, which was likely the intention of the original patch. Fixes: #5820 Fixes: #5257 PR-URL: #6023 Reviewed-By: Brian White <mscdex@mscdex.net> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
In 6899094 (#2325), the conditions for increasing `readableState.awaitDrain` when writing to a piping destination returns false were changed so that they could not actually be met, effectively leaving `readableState.awaitDrain` with a constant value of 0. This patch changes the conditions to testing whether the stream for which `.write()` returned false is still a piping destination, which was likely the intention of the original patch. Fixes: #5820 Fixes: #5257 PR-URL: #6023 Reviewed-By: Brian White <mscdex@mscdex.net> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
In 6899094 (#2325), the conditions for increasing `readableState.awaitDrain` when writing to a piping destination returns false were changed so that they could not actually be met, effectively leaving `readableState.awaitDrain` with a constant value of 0. This patch changes the conditions to testing whether the stream for which `.write()` returned false is still a piping destination, which was likely the intention of the original patch. Fixes: #5820 Fixes: #5257 PR-URL: #6023 Reviewed-By: Brian White <mscdex@mscdex.net> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
In 6899094 (#2325), the conditions for increasing `readableState.awaitDrain` when writing to a piping destination returns false were changed so that they could not actually be met, effectively leaving `readableState.awaitDrain` with a constant value of 0. This patch changes the conditions to testing whether the stream for which `.write()` returned false is still a piping destination, which was likely the intention of the original patch. Fixes: #5820 Fixes: #5257 PR-URL: #6023 Reviewed-By: Brian White <mscdex@mscdex.net> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
In 6899094 (#2325), the conditions for increasing `readableState.awaitDrain` when writing to a piping destination returns false were changed so that they could not actually be met, effectively leaving `readableState.awaitDrain` with a constant value of 0. This patch changes the conditions to testing whether the stream for which `.write()` returned false is still a piping destination, which was likely the intention of the original patch. Fixes: #5820 Fixes: #5257 PR-URL: #6023 Reviewed-By: Brian White <mscdex@mscdex.net> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
In 6899094 (#2325), the conditions for increasing `readableState.awaitDrain` when writing to a piping destination returns false were changed so that they could not actually be met, effectively leaving `readableState.awaitDrain` with a constant value of 0. This patch changes the conditions to testing whether the stream for which `.write()` returned false is still a piping destination, which was likely the intention of the original patch. Fixes: #5820 Fixes: #5257 PR-URL: #6023 Reviewed-By: Brian White <mscdex@mscdex.net> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
In 6899094 (#2325), the conditions for increasing `readableState.awaitDrain` when writing to a piping destination returns false were changed so that they could not actually be met, effectively leaving `readableState.awaitDrain` with a constant value of 0. This patch changes the conditions to testing whether the stream for which `.write()` returned false is still a piping destination, which was likely the intention of the original patch. Fixes: #5820 Fixes: #5257 PR-URL: #6023 Reviewed-By: Brian White <mscdex@mscdex.net> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Pull Request check-list
Please make sure to review and check all of these items:
make -j8 test
(UNIX) orvcbuild test nosign
(Windows) pass withthis change (including linting)?
test (or a benchmark) included?
Is a documentation update included (if this change modifiesexisting APIs, or introduces new ones)?
Affected core subsystem(s)
stream
Description of change
In 6899094 (#2325), the conditions for increasing
readableState.awaitDrain
when writing to a piping destination returns false were changed so that they could not actually be met, effectively leavingreadableState.awaitDrain
with a constant value of 0.This patch changes the conditions to testing whether the stream for which
.write()
returned false is still a piping destination, which was likely the intention of the original patch.Fixes: #5820
/cc @mscdex