Skip to content
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

Closed

Conversation

addaleax
Copy link
Member

@addaleax addaleax commented Apr 2, 2016

Pull Request check-list

Please make sure to review and check all of these items:

  • Does make -j8 test (UNIX) or vcbuild test nosign (Windows) pass with
    this change (including linting)?
  • Is the commit message formatted according to CONTRIBUTING.md?
  • If this change fixes a bug (or a performance problem), is a regression
    test (or a benchmark) included?
  • Is a documentation update included (if this change modifies
    existing 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 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

/cc @mscdex

@addaleax addaleax force-pushed the fix-readablestate-awaitdrain branch from 138b59d to 4b07c8f Compare April 2, 2016 22:38
@Fishrock123 Fishrock123 added the stream Issues and PRs related to the stream subsystem. label Apr 2, 2016
@Fishrock123
Copy link
Contributor

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))) &&
Copy link
Contributor

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?

Copy link
Member Author

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.

Copy link
Contributor

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.

Copy link
Member Author

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
@addaleax addaleax force-pushed the fix-readablestate-awaitdrain branch from 4b07c8f to 21f7246 Compare April 3, 2016 13:31
@mscdex
Copy link
Contributor

mscdex commented Apr 3, 2016

LGTM. CI once more: https://ci.nodejs.org/job/node-test-pull-request/2142/

@jasnell
Copy link
Member

jasnell commented Apr 4, 2016

CI failure looks unrelated.

@mcollina
Copy link
Member

mcollina commented Apr 4, 2016

LGTM

@addaleax
Copy link
Member Author

Btw, whoever lands this can add #5257 to the Fixes: list, #5820 is more or less a duplicate of that one :)

@jasnell
Copy link
Member

jasnell commented Apr 12, 2016

LGTM

jasnell pushed a commit that referenced this pull request Apr 12, 2016
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 <[email protected]>
Reviewed-By: Matteo Collina <[email protected]>
Reviewed-By: James M Snell <[email protected]>
@jasnell
Copy link
Member

jasnell commented Apr 12, 2016

Landed in 819b2d3

@jasnell jasnell closed this Apr 12, 2016
@addaleax addaleax deleted the fix-readablestate-awaitdrain branch April 12, 2016 05:57
MylesBorins pushed a commit that referenced this pull request Apr 19, 2016
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 <[email protected]>
Reviewed-By: Matteo Collina <[email protected]>
Reviewed-By: James M Snell <[email protected]>
MylesBorins pushed a commit that referenced this pull request Apr 20, 2016
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 <[email protected]>
Reviewed-By: Matteo Collina <[email protected]>
Reviewed-By: James M Snell <[email protected]>
@MylesBorins MylesBorins mentioned this pull request Apr 20, 2016
MylesBorins pushed a commit that referenced this pull request Apr 20, 2016
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 <[email protected]>
Reviewed-By: Matteo Collina <[email protected]>
Reviewed-By: James M Snell <[email protected]>
This was referenced Apr 21, 2016
jasnell pushed a commit that referenced this pull request Apr 26, 2016
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 <[email protected]>
Reviewed-By: Matteo Collina <[email protected]>
Reviewed-By: James M Snell <[email protected]>
MylesBorins pushed a commit that referenced this pull request Apr 30, 2016
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 <[email protected]>
Reviewed-By: Matteo Collina <[email protected]>
Reviewed-By: James M Snell <[email protected]>
MylesBorins pushed a commit that referenced this pull request May 6, 2016
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 <[email protected]>
Reviewed-By: Matteo Collina <[email protected]>
Reviewed-By: James M Snell <[email protected]>
MylesBorins pushed a commit that referenced this pull request May 18, 2016
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 <[email protected]>
Reviewed-By: Matteo Collina <[email protected]>
Reviewed-By: James M Snell <[email protected]>
@MylesBorins MylesBorins mentioned this pull request May 18, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stream Issues and PRs related to the stream subsystem.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Piping readable stream to multiple writeable streams results in crash
6 participants