lukechilds/node - node - Gitea: Git with a cup of tea

16887 Commits

131 Branches

446 Tags

325 MiB

Tree: 4a5a9445b5

Commit Graph

Author	SHA1	Message	Date
Mark	21a077ae9a	test: tests for _readableStream.awaitDrain Fixes: https://github.com/nodejs/node/issues/8684 PR-URL: https://github.com/nodejs/node/pull/8914 Reviewed-By: Matteo Collina <matteo.collina@gmail.com>	8 years ago
Anna Henningsen	e2e615e87e	stream: reset awaitDrain after manual .resume() Reset the `readableState.awaitDrain` counter after manual calls to `.resume()`. What might happen otherwise is that a slow consumer at the end of the pipe could end up stalling the piping in the following scenario: 1. The writable stream indicates that its buffer is full. 2. This leads the readable stream to `pause()` and increase its `awaitDrain` counter, which will be decreased by the writable’s next `drain` event. 3. Something calls `.resume()` manually. 4. The readable continues to pipe to the writable, but once again the writable stream indicates that the buffer is full. 5. The `awaitDrain` counter is thus increased again, but since it has now been increased twice for a single piping destination, the next `drain` event will not be able to reset `awaitDrain` to zero. 6. The pipe is stalled and no data is passed along anymore. The solution in this commit is to reset the `awaitDrain` counter to zero when `resume()` is called. Fixes: https://github.com/nodejs/node/issues/7159 PR-URL: https://github.com/nodejs/node/pull/7160 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>	9 years ago

Author

SHA1

Message

Date

Mark

21a077ae9a

test: tests for _readableStream.awaitDrain

Fixes: https://github.com/nodejs/node/issues/8684
PR-URL: https://github.com/nodejs/node/pull/8914
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>

8 years ago

Anna Henningsen

e2e615e87e

stream: reset awaitDrain after manual .resume()

Reset the `readableState.awaitDrain` counter after manual calls to
`.resume()`.

What might happen otherwise is that a slow consumer at the end of the
pipe could end up stalling the piping in the following scenario:

1. The writable stream indicates that its buffer is full.
2. This leads the readable stream to `pause()` and increase its
   `awaitDrain` counter, which will be decreased by the writable’s next
   `drain` event.
3. Something calls `.resume()` manually.
4. The readable continues to pipe to the writable, but once again
   the writable stream indicates that the buffer is full.
5. The `awaitDrain` counter is thus increased again, but since it has
   now been increased twice for a single piping destination, the next
   `drain` event will not be able to reset `awaitDrain` to zero.
6. The pipe is stalled and no data is passed along anymore.

The solution in this commit is to reset the `awaitDrain` counter to
zero when `resume()` is called.

Fixes: https://github.com/nodejs/node/issues/7159
PR-URL: https://github.com/nodejs/node/pull/7160
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>

9 years ago

2 Commits (4a5a9445b542333ac7cd8e3ea39ac784a16ccd97)