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.
10702 Commits
131 Branches
446 Tags
325 MiB
Tree: 909df70694
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '909df70694'
${ noResults }
node/test/parallel/test-stream2-finish-pipe.js

21 lines
495 B
Raw Normal View History

streams: both `finish` and `close` should unpipe Otherwise sockets that are 'finish'ed won't be unpiped and `writing to ended stream` error will arise. This might sound unrealistic, but it happens in net.js. When `socket.allowHalfOpen === false`, EOF will cause `.destroySoon()` call which ends the writable side of net.Socket.
12 years ago
var common = require('../common.js');
var stream = require('stream');
var Buffer = require('buffer').Buffer;
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
var r = new stream.Readable();
r._read = function(size) {
r.push(new Buffer(size));
streams: both `finish` and `close` should unpipe Otherwise sockets that are 'finish'ed won't be unpiped and `writing to ended stream` error will arise. This might sound unrealistic, but it happens in net.js. When `socket.allowHalfOpen === false`, EOF will cause `.destroySoon()` call which ends the writable side of net.Socket.
12 years ago
};
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
var w = new stream.Writable();
stream: _write takes an encoding argument This vastly reduces the overhead of decodeStrings:false streams, such as net and http.
12 years ago
w._write = function(data, encoding, cb) {
streams: both `finish` and `close` should unpipe Otherwise sockets that are 'finish'ed won't be unpiped and `writing to ended stream` error will arise. This might sound unrealistic, but it happens in net.js. When `socket.allowHalfOpen === false`, EOF will cause `.destroySoon()` call which ends the writable side of net.Socket.
12 years ago
cb(null);
};
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
r.pipe(w);
streams: both `finish` and `close` should unpipe Otherwise sockets that are 'finish'ed won't be unpiped and `writing to ended stream` error will arise. This might sound unrealistic, but it happens in net.js. When `socket.allowHalfOpen === false`, EOF will cause `.destroySoon()` call which ends the writable side of net.Socket.
12 years ago
// This might sound unrealistic, but it happens in net.js. When
// `socket.allowHalfOpen === false`, EOF will cause `.destroySoon()` call which
// ends the writable side of net.Socket.
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
w.end();