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

Author	SHA1	Message	Date
isaacs	0f8de5e1f9	stream: Simplify flowing, passive data listening Closes #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.	12 years ago
isaacs	cd2b9f542c	stream: Avoid nextTick warning filling read buffer In the function that pre-emptively fills the Readable queue, it relies on a recursion through: stream.push(chunk) -> maybeReadMore(stream, state) -> if (not reading more and < hwm) stream.read(0) -> stream._read() -> stream.push(chunk) -> repeat. Since this was only calling read() a single time, and then relying on a future nextTick to collect more data, it ends up causing a nextTick recursion error (and potentially a RangeError, even) if you have a very high highWaterMark, and are getting very small chunks pushed synchronously in _read (as happens with TLS, or many simple test streams). This change implements a new approach, so that read(0) is called repeatedly as long as it is effective (that is, the length keeps increasing), and thus quickly fills up the buffer for streams such as these, without any stacks overflowing.	12 years ago
isaacs	cd68d86c32	stream: Remove output function from _transform Just use stream.push(outputChunk) instead.	12 years ago
isaacs	119cbf4854	stream: Don't require read(0) to emit 'readable' event When a readable listener is added, call read(0) so that data will flow in, up to the high water mark. Otherwise, it's somewhat confusing that you have to listen for readable, and ALSO call read() (when it will certainly return null) just to get some data out of the stream. See: #4720	12 years ago
isaacs	88644eaa2d	stream: There is no _read cb, there is only push This makes it so that `stream.push(chunk)` is the only way to signal the end of reading, removing the confusing disparity between the callback-style _read method, and the fact that most real-world streams do not have a 1:1 corollation between the "please give me data" event, and the actual arrival of a chunk of data. It is still possible, of course, to implement a `CallbackReadable` on top of this. Simply provide a method like this as the callback: function readCallback(er, chunk) { if (er) stream.emit('error', er); else stream.push(chunk); } However, only fs streams actually would behave in this way, so it makes not a lot of sense to make TCP, TLS, HTTP, and all the rest have to bend into this uncomfortable paradigm.	12 years ago
Andreas Madsen	5daa701aba	stream: fix event handler leak in readstream pipe and unpipe After a stream was unpiped there would stil be residual event handlers	12 years ago
Ben Noordhuis	7f4aba91d3	test: include common.js in all tests	13 years ago
Colton Baker	87286cc737	Fixed a lot of jslint errors. Fixes #1831	13 years ago
Ryan Dahl	55048cdf79	Update copyright headers	14 years ago
Mikeal Rogers	634e7236f7	Add 'pipe' event	14 years ago