Conversation
|
Thank you for contributing this pull request! Here are a few pointers to make sure your submission will be considered for inclusion. Commit isaacs/node@e4b98bd has the following error(s):
Commit isaacs/node@a03e638 has the following error(s):
Commit isaacs/node@8f196d3 has the following error(s):
Commit isaacs/node@a7f9678 has the following error(s):
Commit isaacs/node@1e4e3c9 has the following error(s):
Commit isaacs/node@d2fbfb1 has the following error(s):
Commit isaacs/node@29954af has the following error(s):
Commit isaacs/node@b2de7b4 has the following error(s):
Commit isaacs/node@fe96fc8 has the following error(s):
You can fix all these things without opening another issue. Please see CONTRIBUTING.md for more information |
There was a problem hiding this comment.
Looks like so in the doc output:
Calling the [pipe()][] method to send the...
Closes nodejs#5860 In streams2, there is an "old mode" for compatibility. Once switched into this mode, there is no going back. With this change, there is a "flowing mode" and a "paused mode". If you add a data listener, then this will start the flow of data. However, hitting the `pause()` method will switch *back* into a non-flowing mode, where the `read()` method will pull data out. Every time `read()` returns a data chunk, it also emits a `data` event. In this way, a passive data listener can be added, and the stream passed off to some other reader, for use with progress bars and the like. There is no API change beyond this added flexibility.
This addresses #5860.
Performance-wise it seems to be on-par with master, and I haven't gone through and worked out any trouble spots with the V8 profiling tools.
The commits are a mess, and will be squashed of course, but the best way to see the high level view of what this enables is to check out https://github.com/isaacs/node/blob/streams3/test/simple/test-stream3-pause-then-read.js. That test would switch a streams2 stream into old-mode, but with streams3, you hit
s.pause()and it's right back where it was.The other semantic change is that adding a
readableevent handler will not causereadableto be emitted until nextTick. Otherwise, stuff like this is problematic:All other semantics should be identical to master. API should be identical.
Still todo: docs.
Review/feedback please: @jclulow @bnoordhuis @indutny @Raynos @tjfontaine