lukechilds
/
node
mirror of https://github.com/lukechilds/node.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
14593 Commits
131 Branches
446 Tags
325 MiB
Tree: 1b99093df7
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '1b99093df7'
${ noResults }
node/test/parallel/test-stream2-readable-non-e...

52 lines
1.1 KiB
Raw Normal View History

test: enable linting for tests Enable linting for the test directory. A number of changes was made so all tests conform the current rules used by lib and src directories. The only exception for tests is that unreachable (dead) code is allowed. test-fs-non-number-arguments-throw had to be excluded from the changes because of a weird issue on Windows CI. PR-URL: https://github.com/nodejs/io.js/pull/1721 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
10 years ago
'use strict';
test: use mustCall() for simple flow tracking Many of the tests use variables to track when callback functions are invoked or events are emitted. These variables are then asserted on process exit. This commit replaces this pattern in straightforward cases with common.mustCall(). This makes the tests easier to reason about, leads to a net reduction in lines of code, and uncovered a few bugs in tests. This commit also replaces some callbacks that should never be called with common.fail(). PR-URL: https://github.com/nodejs/node/pull/7753 Reviewed-By: Wyatt Preul <wpreul@gmail.com> Reviewed-By: Minwoo Jung <jmwsoft@gmail.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
9 years ago
const common = require('../common');
stream: Do not call endReadable on a non-empty stream Say that a stream's current read queue has 101 bytes in it, and the underlying resource has ended (ie, reached EOF). If you do something like this: stream.read(100); // leave a byte behind stream.read(0); // read(0) for some reason then the read(0) will get 0 from the howMuchToRead function. Since the stream was ended, this was incorrectly treating the 0 as a "there is no more in the buffer", and emitting 'end' before that last byte was read. Why have the read(0) in the first place? We do this in some cases to trigger the last few bytes of a net socket (such as a child process's stdio pipes). This was causing issues when piping a `git archive` job to a file: the resulting tarball was incomplete, because it occasionally was not getting the last chunk.
12 years ago
var assert = require('assert');
var Readable = require('_stream_readable');
var len = 0;
var chunks = new Array(10);
for (var i = 1; i <= 10; i++) {
buffer: add .from(), .alloc() and .allocUnsafe() Several changes: * Soft-Deprecate Buffer() constructors * Add `Buffer.from()`, `Buffer.alloc()`, and `Buffer.allocUnsafe()` * Add `--zero-fill-buffers` command line option * Add byteOffset and length to `new Buffer(arrayBuffer)` constructor * buffer.fill(&#39;&#39;) previously had no effect, now zero-fills * Update the docs PR-URL: https://github.com/nodejs/node/pull/4682 Reviewed-By: Сковорода Никита Андреевич &lt;chalkerx@gmail.com&gt; Reviewed-By: Stephen Belanger &lt;admin@stephenbelanger.com&gt;
9 years ago
chunks[i - 1] = Buffer.allocUnsafe(i);
stream: Do not call endReadable on a non-empty stream Say that a stream&#39;s current read queue has 101 bytes in it, and the underlying resource has ended (ie, reached EOF). If you do something like this: stream.read(100); // leave a byte behind stream.read(0); // read(0) for some reason then the read(0) will get 0 from the howMuchToRead function. Since the stream was ended, this was incorrectly treating the 0 as a &#34;there is no more in the buffer&#34;, and emitting &#39;end&#39; before that last byte was read. Why have the read(0) in the first place? We do this in some cases to trigger the last few bytes of a net socket (such as a child process&#39;s stdio pipes). This was causing issues when piping a `git archive` job to a file: the resulting tarball was incomplete, because it occasionally was not getting the last chunk.
12 years ago
len += i;
}
var test = new Readable();
var n = 0;
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 &#34;please give me data&#34; 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(&#39;error&#39;, 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
test._read = function(size) {
stream: Do not call endReadable on a non-empty stream Say that a stream&#39;s current read queue has 101 bytes in it, and the underlying resource has ended (ie, reached EOF). If you do something like this: stream.read(100); // leave a byte behind stream.read(0); // read(0) for some reason then the read(0) will get 0 from the howMuchToRead function. Since the stream was ended, this was incorrectly treating the 0 as a &#34;there is no more in the buffer&#34;, and emitting &#39;end&#39; before that last byte was read. Why have the read(0) in the first place? We do this in some cases to trigger the last few bytes of a net socket (such as a child process&#39;s stdio pipes). This was causing issues when piping a `git archive` job to a file: the resulting tarball was incomplete, because it occasionally was not getting the last chunk.
12 years ago
var chunk = chunks[n++];
setTimeout(function() {
stream: only end reading on null, not undefined The [Stream documentation for .push](http://nodejs.org/api/stream.html#stream_readable_push_chunk_encoding) explicitly states multiple times that null is a special cased value that indicates the end of a stream. It is confusing and undocumented that undefined *also* ends the stream, even though in object mode there is a distinct and important difference. The docs for Object-Mode also explicitly mention null as the *only* special cased value, making no mention of undefined. Signed-off-by: Fedor Indutny &lt;fedor@indutny.com&gt;
11 years ago
test.push(chunk === undefined ? null : chunk);
stream: Do not call endReadable on a non-empty stream Say that a stream&#39;s current read queue has 101 bytes in it, and the underlying resource has ended (ie, reached EOF). If you do something like this: stream.read(100); // leave a byte behind stream.read(0); // read(0) for some reason then the read(0) will get 0 from the howMuchToRead function. Since the stream was ended, this was incorrectly treating the 0 as a &#34;there is no more in the buffer&#34;, and emitting &#39;end&#39; before that last byte was read. Why have the read(0) in the first place? We do this in some cases to trigger the last few bytes of a net socket (such as a child process&#39;s stdio pipes). This was causing issues when piping a `git archive` job to a file: the resulting tarball was incomplete, because it occasionally was not getting the last chunk.
12 years ago
});
};
test.on('end', thrower);
function thrower() {
throw new Error('this should not happen!');
}
var bytesread = 0;
test.on('readable', function() {
var b = len - bytesread - 1;
var res = test.read(b);
if (res) {
bytesread += res.length;
console.error('br=%d len=%d', bytesread, len);
setTimeout(next);
}
test.read(0);
});
test.read(0);
function next() {
// now let's make 'end' happen
test.removeListener('end', thrower);
test: use mustCall() for simple flow tracking Many of the tests use variables to track when callback functions are invoked or events are emitted. These variables are then asserted on process exit. This commit replaces this pattern in straightforward cases with common.mustCall(). This makes the tests easier to reason about, leads to a net reduction in lines of code, and uncovered a few bugs in tests. This commit also replaces some callbacks that should never be called with common.fail(). PR-URL: https://github.com/nodejs/node/pull/7753 Reviewed-By: Wyatt Preul &lt;wpreul@gmail.com&gt; Reviewed-By: Minwoo Jung &lt;jmwsoft@gmail.com&gt; Reviewed-By: Ben Noordhuis &lt;info@bnoordhuis.nl&gt;
9 years ago
test.on('end', common.mustCall(function() {}));
stream: Do not call endReadable on a non-empty stream Say that a stream&#39;s current read queue has 101 bytes in it, and the underlying resource has ended (ie, reached EOF). If you do something like this: stream.read(100); // leave a byte behind stream.read(0); // read(0) for some reason then the read(0) will get 0 from the howMuchToRead function. Since the stream was ended, this was incorrectly treating the 0 as a &#34;there is no more in the buffer&#34;, and emitting &#39;end&#39; before that last byte was read. Why have the read(0) in the first place? We do this in some cases to trigger the last few bytes of a net socket (such as a child process&#39;s stdio pipes). This was causing issues when piping a `git archive` job to a file: the resulting tarball was incomplete, because it occasionally was not getting the last chunk.
12 years ago
// one to get the last byte
var r = test.read();
assert(r);
assert.equal(r.length, 1);
r = test.read();
assert.equal(r, null);
}