2017-01-03 22:16:48 +01:00
|
|
|
// Copyright Joyent, Inc. and other Node contributors.
|
|
|
|
//
|
|
|
|
// Permission is hereby granted, free of charge, to any person obtaining a
|
|
|
|
// copy of this software and associated documentation files (the
|
|
|
|
// "Software"), to deal in the Software without restriction, including
|
|
|
|
// without limitation the rights to use, copy, modify, merge, publish,
|
|
|
|
// distribute, sublicense, and/or sell copies of the Software, and to permit
|
|
|
|
// persons to whom the Software is furnished to do so, subject to the
|
|
|
|
// following conditions:
|
|
|
|
//
|
|
|
|
// The above copyright notice and this permission notice shall be included
|
|
|
|
// in all copies or substantial portions of the Software.
|
|
|
|
//
|
|
|
|
// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
|
|
|
|
// OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
|
|
|
|
// MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN
|
|
|
|
// NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
|
|
|
|
// DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
|
|
|
|
// OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
|
|
|
|
// USE OR OTHER DEALINGS IN THE SOFTWARE.
|
|
|
|
|
2014-11-22 16:59:48 +01:00
|
|
|
'use strict';
|
|
|
|
|
2012-10-03 00:44:50 +02:00
|
|
|
module.exports = Readable;
|
2012-11-13 08:30:10 +01:00
|
|
|
Readable.ReadableState = ReadableState;
|
2012-10-03 00:44:50 +02:00
|
|
|
|
2015-09-17 00:45:29 +02:00
|
|
|
const EE = require('events');
|
2015-01-21 17:36:59 +01:00
|
|
|
const Stream = require('stream');
|
2017-10-07 16:50:42 +02:00
|
|
|
const { Buffer } = require('buffer');
|
2019-03-06 12:54:12 +01:00
|
|
|
|
|
|
|
let debuglog;
|
|
|
|
function debug(...args) {
|
|
|
|
if (!debuglog) {
|
|
|
|
debuglog = require('internal/util/debuglog').debuglog('stream');
|
|
|
|
}
|
|
|
|
debuglog(...args);
|
|
|
|
}
|
|
|
|
|
2018-03-23 15:32:23 +01:00
|
|
|
const BufferList = require('internal/streams/buffer_list');
|
2017-05-06 14:20:52 +02:00
|
|
|
const destroyImpl = require('internal/streams/destroy');
|
2018-01-09 20:39:29 +01:00
|
|
|
const { getHighWaterMark } = require('internal/streams/state');
|
2018-03-04 22:16:24 +01:00
|
|
|
const {
|
|
|
|
ERR_INVALID_ARG_TYPE,
|
|
|
|
ERR_STREAM_PUSH_AFTER_EOF,
|
2018-02-16 12:53:34 +01:00
|
|
|
ERR_METHOD_NOT_IMPLEMENTED,
|
2018-03-04 22:16:24 +01:00
|
|
|
ERR_STREAM_UNSHIFT_AFTER_END_EVENT
|
|
|
|
} = require('internal/errors').codes;
|
2017-12-19 13:33:31 +01:00
|
|
|
const { emitExperimentalWarning } = require('internal/util');
|
2018-05-06 23:08:00 +02:00
|
|
|
|
|
|
|
// Lazy loaded to improve the startup performance.
|
|
|
|
let StringDecoder;
|
2018-09-23 22:10:12 +02:00
|
|
|
let createReadableStreamAsyncIterator;
|
2012-10-03 00:44:50 +02:00
|
|
|
|
2018-11-30 17:55:48 +01:00
|
|
|
Object.setPrototypeOf(Readable.prototype, Stream.prototype);
|
2018-12-02 15:03:01 +01:00
|
|
|
Object.setPrototypeOf(Readable, Stream);
|
2012-10-03 00:44:50 +02:00
|
|
|
|
2018-08-21 20:05:12 +02:00
|
|
|
const { errorOrDestroy } = destroyImpl;
|
2017-02-26 07:16:57 +01:00
|
|
|
const kProxyEvents = ['error', 'close', 'destroy', 'pause', 'resume'];
|
|
|
|
|
2016-08-08 19:32:26 +02:00
|
|
|
function prependListener(emitter, event, fn) {
|
|
|
|
// Sadly this is not cacheable as some libraries bundle their own
|
|
|
|
// event emitter implementation with them.
|
2017-10-17 00:37:14 +02:00
|
|
|
if (typeof emitter.prependListener === 'function')
|
2016-04-04 04:55:22 +02:00
|
|
|
return emitter.prependListener(event, fn);
|
2017-10-17 00:37:14 +02:00
|
|
|
|
|
|
|
// This is a hack to make sure that our error handler is attached before any
|
|
|
|
// userland ones. NEVER DO THIS. This is here only because this code needs
|
|
|
|
// to continue to work with older versions of Node.js that do not include
|
|
|
|
// the prependListener() method. The goal is to eventually remove this hack.
|
|
|
|
if (!emitter._events || !emitter._events[event])
|
|
|
|
emitter.on(event, fn);
|
|
|
|
else if (Array.isArray(emitter._events[event]))
|
|
|
|
emitter._events[event].unshift(fn);
|
|
|
|
else
|
|
|
|
emitter._events[event] = [fn, emitter._events[event]];
|
2016-04-04 04:55:22 +02:00
|
|
|
}
|
|
|
|
|
2018-03-17 01:35:32 +01:00
|
|
|
function ReadableState(options, stream, isDuplex) {
|
2012-10-03 00:44:50 +02:00
|
|
|
options = options || {};
|
|
|
|
|
2017-08-05 01:12:24 +02:00
|
|
|
// Duplex streams are both readable and writable, but share
|
|
|
|
// the same options object.
|
|
|
|
// However, some cases require setting options to different
|
|
|
|
// values for the readable and the writable sides of the duplex stream.
|
|
|
|
// These options can be provided separately as readableXXX and writableXXX.
|
2018-03-17 01:35:32 +01:00
|
|
|
if (typeof isDuplex !== 'boolean')
|
|
|
|
isDuplex = stream instanceof Stream.Duplex;
|
2017-08-05 01:12:24 +02:00
|
|
|
|
2018-12-10 13:27:32 +01:00
|
|
|
// Object stream flag. Used to make read(n) ignore n and to
|
2014-07-09 00:06:40 +02:00
|
|
|
// make all the buffer merging and length checks go away
|
|
|
|
this.objectMode = !!options.objectMode;
|
|
|
|
|
2017-08-05 01:12:24 +02:00
|
|
|
if (isDuplex)
|
2014-07-09 00:06:40 +02:00
|
|
|
this.objectMode = this.objectMode || !!options.readableObjectMode;
|
|
|
|
|
2018-12-03 17:15:45 +01:00
|
|
|
// The point at which it stops calling _read() to fill the buffer
|
2012-12-19 03:49:42 +01:00
|
|
|
// Note: 0 is a valid value, means "don't call _read preemptively ever"
|
2018-01-09 20:39:29 +01:00
|
|
|
this.highWaterMark = getHighWaterMark(this, options, 'readableHighWaterMark',
|
|
|
|
isDuplex);
|
2012-11-13 08:31:25 +01:00
|
|
|
|
2016-05-31 19:03:59 +02:00
|
|
|
// A linked list is used to store data chunks instead of an array because the
|
|
|
|
// linked list can remove elements from the beginning faster than
|
|
|
|
// array.shift()
|
|
|
|
this.buffer = new BufferList();
|
2012-10-03 00:44:50 +02:00
|
|
|
this.length = 0;
|
2012-11-17 04:27:41 +01:00
|
|
|
this.pipes = null;
|
|
|
|
this.pipesCount = 0;
|
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.
2013-07-18 03:24:02 +02:00
|
|
|
this.flowing = null;
|
2012-10-03 00:44:50 +02:00
|
|
|
this.ended = false;
|
2012-10-04 01:52:14 +02:00
|
|
|
this.endEmitted = false;
|
2012-10-03 00:44:50 +02:00
|
|
|
this.reading = false;
|
2013-02-23 01:45:22 +01:00
|
|
|
|
2018-12-03 17:15:45 +01:00
|
|
|
// A flag to be able to tell if the event 'readable'/'data' is emitted
|
2017-02-03 07:00:20 +01:00
|
|
|
// immediately, or on a later tick. We set this to true at first, because
|
|
|
|
// any actions that shouldn't happen until "later" should generally also
|
|
|
|
// not happen before the first read call.
|
2013-02-23 01:45:22 +01:00
|
|
|
this.sync = true;
|
|
|
|
|
2018-12-10 13:27:32 +01:00
|
|
|
// Whenever we return null, then we set a flag to say
|
2012-10-03 00:44:50 +02:00
|
|
|
// that we're awaiting a 'readable' event emission.
|
|
|
|
this.needReadable = false;
|
2012-11-13 08:32:05 +01:00
|
|
|
this.emittedReadable = false;
|
2013-03-26 22:42:56 +01:00
|
|
|
this.readableListening = false;
|
2016-01-19 15:53:38 +01:00
|
|
|
this.resumeScheduled = false;
|
2018-11-14 17:23:28 +01:00
|
|
|
this.paused = true;
|
2012-10-04 01:52:14 +02:00
|
|
|
|
2018-01-29 19:32:34 +01:00
|
|
|
// Should close be emitted on destroy. Defaults to true.
|
|
|
|
this.emitClose = options.emitClose !== false;
|
|
|
|
|
2018-08-21 20:05:12 +02:00
|
|
|
// Should .destroy() be called after 'end' (and potentially 'finish')
|
|
|
|
this.autoDestroy = !!options.autoDestroy;
|
|
|
|
|
2019-03-22 03:44:26 +01:00
|
|
|
// Has it been destroyed
|
2017-05-06 14:20:52 +02:00
|
|
|
this.destroyed = false;
|
|
|
|
|
2013-05-02 21:25:50 +02:00
|
|
|
// Crypto is kind of old and crusty. Historically, its default string
|
|
|
|
// encoding is 'binary' so we have to make this configurable.
|
|
|
|
// Everything else in the universe uses 'utf8', though.
|
|
|
|
this.defaultEncoding = options.defaultEncoding || 'utf8';
|
|
|
|
|
2018-12-03 17:15:45 +01:00
|
|
|
// The number of writers that are awaiting a drain event in .pipe()s
|
2012-11-28 10:25:39 +01:00
|
|
|
this.awaitDrain = 0;
|
2012-11-28 03:20:16 +01:00
|
|
|
|
2019-01-21 01:22:27 +01:00
|
|
|
// If true, a maybeReadMore has been scheduled
|
2013-03-08 09:26:53 +01:00
|
|
|
this.readingMore = false;
|
|
|
|
|
2012-10-04 01:52:14 +02:00
|
|
|
this.decoder = null;
|
2013-05-01 00:09:54 +02:00
|
|
|
this.encoding = null;
|
2012-10-04 01:52:14 +02:00
|
|
|
if (options.encoding) {
|
|
|
|
if (!StringDecoder)
|
|
|
|
StringDecoder = require('string_decoder').StringDecoder;
|
|
|
|
this.decoder = new StringDecoder(options.encoding);
|
2013-05-01 00:09:54 +02:00
|
|
|
this.encoding = options.encoding;
|
2012-10-04 01:52:14 +02:00
|
|
|
}
|
2012-10-03 00:44:50 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
function Readable(options) {
|
2012-10-08 23:43:17 +02:00
|
|
|
if (!(this instanceof Readable))
|
|
|
|
return new Readable(options);
|
|
|
|
|
2018-03-17 01:35:32 +01:00
|
|
|
// Checking for a Stream.Duplex instance is faster here instead of inside
|
|
|
|
// the ReadableState constructor, at least with V8 6.5
|
2018-08-22 06:15:00 +02:00
|
|
|
const isDuplex = this instanceof Stream.Duplex;
|
2018-03-17 01:35:32 +01:00
|
|
|
|
|
|
|
this._readableState = new ReadableState(options, this, isDuplex);
|
2012-11-28 03:21:05 +01:00
|
|
|
|
|
|
|
// legacy
|
|
|
|
this.readable = true;
|
|
|
|
|
2017-05-06 14:20:52 +02:00
|
|
|
if (options) {
|
|
|
|
if (typeof options.read === 'function')
|
|
|
|
this._read = options.read;
|
|
|
|
|
|
|
|
if (typeof options.destroy === 'function')
|
|
|
|
this._destroy = options.destroy;
|
|
|
|
}
|
2015-02-03 02:12:41 +01:00
|
|
|
|
2012-12-27 17:30:50 +01:00
|
|
|
Stream.call(this);
|
2012-10-03 00:44:50 +02:00
|
|
|
}
|
|
|
|
|
2017-05-06 14:20:52 +02:00
|
|
|
Object.defineProperty(Readable.prototype, 'destroyed', {
|
2018-12-10 13:27:32 +01:00
|
|
|
// Making it explicit this property is not enumerable
|
2017-05-05 14:42:21 +02:00
|
|
|
// because otherwise some prototype manipulation in
|
|
|
|
// userland will fail
|
|
|
|
enumerable: false,
|
2017-05-06 14:20:52 +02:00
|
|
|
get() {
|
|
|
|
if (this._readableState === undefined) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return this._readableState.destroyed;
|
|
|
|
},
|
|
|
|
set(value) {
|
2019-03-07 01:03:53 +01:00
|
|
|
// We ignore the value if the stream
|
2017-05-06 14:20:52 +02:00
|
|
|
// has not been initialized yet
|
|
|
|
if (!this._readableState) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2019-01-21 01:22:27 +01:00
|
|
|
// Backward compatibility, the user is explicitly
|
2017-05-06 14:20:52 +02:00
|
|
|
// managing destroyed
|
|
|
|
this._readableState.destroyed = value;
|
|
|
|
}
|
|
|
|
});
|
|
|
|
|
|
|
|
Readable.prototype.destroy = destroyImpl.destroy;
|
|
|
|
Readable.prototype._undestroy = destroyImpl.undestroy;
|
|
|
|
Readable.prototype._destroy = function(err, cb) {
|
|
|
|
cb(err);
|
|
|
|
};
|
|
|
|
|
2013-01-08 03:07:17 +01:00
|
|
|
// Manually shove something into the read() buffer.
|
|
|
|
// This returns true if the highWaterMark has not been hit yet,
|
|
|
|
// similar to how Writable.write() returns true if you should
|
|
|
|
// write() some more.
|
2013-05-01 00:09:54 +02:00
|
|
|
Readable.prototype.push = function(chunk, encoding) {
|
2013-02-28 01:56:30 +01:00
|
|
|
var state = this._readableState;
|
2017-05-19 10:07:53 +02:00
|
|
|
var skipChunkCheck;
|
|
|
|
|
|
|
|
if (!state.objectMode) {
|
|
|
|
if (typeof chunk === 'string') {
|
|
|
|
encoding = encoding || state.defaultEncoding;
|
|
|
|
if (encoding !== state.encoding) {
|
|
|
|
chunk = Buffer.from(chunk, encoding);
|
|
|
|
encoding = '';
|
|
|
|
}
|
|
|
|
skipChunkCheck = true;
|
2013-05-01 00:09:54 +02:00
|
|
|
}
|
2017-05-19 10:07:53 +02:00
|
|
|
} else {
|
|
|
|
skipChunkCheck = true;
|
2013-05-01 00:09:54 +02:00
|
|
|
}
|
|
|
|
|
2017-05-19 10:07:53 +02:00
|
|
|
return readableAddChunk(this, chunk, encoding, false, skipChunkCheck);
|
2013-01-08 03:07:17 +01:00
|
|
|
};
|
|
|
|
|
2013-05-01 00:09:54 +02:00
|
|
|
// Unshift should *always* be something directly out of read()
|
2013-02-28 04:32:19 +01:00
|
|
|
Readable.prototype.unshift = function(chunk) {
|
2017-05-19 10:07:53 +02:00
|
|
|
return readableAddChunk(this, chunk, null, true, false);
|
2013-02-28 04:32:19 +01:00
|
|
|
};
|
|
|
|
|
2017-05-19 10:07:53 +02:00
|
|
|
function readableAddChunk(stream, chunk, encoding, addToFront, skipChunkCheck) {
|
2018-02-26 09:24:30 +01:00
|
|
|
debug('readableAddChunk', chunk);
|
2017-05-19 10:07:53 +02:00
|
|
|
var state = stream._readableState;
|
|
|
|
if (chunk === null) {
|
stream: Fix unshift() race conditions
Fix #5272
The consumption of a readable stream is a dance with 3 partners.
1. The specific stream Author (A)
2. The Stream Base class (B), and
3. The Consumer of the stream (C)
When B calls the _read() method that A implements, it sets a 'reading'
flag, so that parallel calls to _read() can be avoided. When A calls
stream.push(), B knows that it's safe to start calling _read() again.
If the consumer C is some kind of parser that wants in some cases to
pass the source stream off to some other party, but not before "putting
back" some bit of previously consumed data (as in the case of Node's
websocket http upgrade implementation). So, stream.unshift() will
generally *never* be called by A, but *only* called by C.
Prior to this patch, stream.unshift() *also* unset the state.reading
flag, meaning that C could indicate the end of a read, and B would
dutifully fire off another _read() call to A. This is inappropriate.
In the case of fs streams, and other variably-laggy streams that don't
tolerate overlapped _read() calls, this causes big problems.
Also, calling stream.shift() after the 'end' event did not raise any
kind of error, but would cause very strange behavior indeed. Calling it
after the EOF chunk was seen, but before the 'end' event was fired would
also cause weird behavior, and could lead to data being lost, since it
would not emit another 'readable' event.
This change makes it so that:
1. stream.unshift() does *not* set state.reading = false
2. stream.unshift() is allowed up until the 'end' event.
3. unshifting onto a EOF-encountered and zero-length (but not yet
end-emitted) stream will defer the 'end' event until the new data is
consumed.
4. pushing onto a EOF-encountered stream is now an error.
So, if you read(), you have that single tick to safely unshift() data
back into the stream, even if the null chunk was pushed, and the length
was 0.
2013-04-12 00:01:26 +02:00
|
|
|
state.reading = false;
|
2014-10-02 18:00:40 +02:00
|
|
|
onEofChunk(stream, state);
|
2017-05-19 10:07:53 +02:00
|
|
|
} else {
|
|
|
|
var er;
|
|
|
|
if (!skipChunkCheck)
|
|
|
|
er = chunkInvalid(state, chunk);
|
|
|
|
if (er) {
|
2018-08-21 20:05:12 +02:00
|
|
|
errorOrDestroy(stream, er);
|
2017-05-19 10:07:53 +02:00
|
|
|
} else if (state.objectMode || chunk && chunk.length > 0) {
|
2017-01-09 19:05:06 +01:00
|
|
|
if (typeof chunk !== 'string' &&
|
2017-06-18 12:03:38 +02:00
|
|
|
!state.objectMode &&
|
|
|
|
Object.getPrototypeOf(chunk) !== Buffer.prototype) {
|
2017-01-09 19:05:06 +01:00
|
|
|
chunk = Stream._uint8ArrayToBuffer(chunk);
|
|
|
|
}
|
|
|
|
|
2017-05-19 10:07:53 +02:00
|
|
|
if (addToFront) {
|
|
|
|
if (state.endEmitted)
|
2018-08-21 20:05:12 +02:00
|
|
|
errorOrDestroy(stream, new ERR_STREAM_UNSHIFT_AFTER_END_EVENT());
|
2017-05-19 10:07:53 +02:00
|
|
|
else
|
|
|
|
addChunk(stream, state, chunk, true);
|
|
|
|
} else if (state.ended) {
|
2018-08-21 20:05:12 +02:00
|
|
|
errorOrDestroy(stream, new ERR_STREAM_PUSH_AFTER_EOF());
|
2018-01-29 19:32:34 +01:00
|
|
|
} else if (state.destroyed) {
|
|
|
|
return false;
|
2017-05-19 10:07:53 +02:00
|
|
|
} else {
|
stream: Fix unshift() race conditions
Fix #5272
The consumption of a readable stream is a dance with 3 partners.
1. The specific stream Author (A)
2. The Stream Base class (B), and
3. The Consumer of the stream (C)
When B calls the _read() method that A implements, it sets a 'reading'
flag, so that parallel calls to _read() can be avoided. When A calls
stream.push(), B knows that it's safe to start calling _read() again.
If the consumer C is some kind of parser that wants in some cases to
pass the source stream off to some other party, but not before "putting
back" some bit of previously consumed data (as in the case of Node's
websocket http upgrade implementation). So, stream.unshift() will
generally *never* be called by A, but *only* called by C.
Prior to this patch, stream.unshift() *also* unset the state.reading
flag, meaning that C could indicate the end of a read, and B would
dutifully fire off another _read() call to A. This is inappropriate.
In the case of fs streams, and other variably-laggy streams that don't
tolerate overlapped _read() calls, this causes big problems.
Also, calling stream.shift() after the 'end' event did not raise any
kind of error, but would cause very strange behavior indeed. Calling it
after the EOF chunk was seen, but before the 'end' event was fired would
also cause weird behavior, and could lead to data being lost, since it
would not emit another 'readable' event.
This change makes it so that:
1. stream.unshift() does *not* set state.reading = false
2. stream.unshift() is allowed up until the 'end' event.
3. unshifting onto a EOF-encountered and zero-length (but not yet
end-emitted) stream will defer the 'end' event until the new data is
consumed.
4. pushing onto a EOF-encountered stream is now an error.
So, if you read(), you have that single tick to safely unshift() data
back into the stream, even if the null chunk was pushed, and the length
was 0.
2013-04-12 00:01:26 +02:00
|
|
|
state.reading = false;
|
2017-05-19 10:07:53 +02:00
|
|
|
if (state.decoder && !encoding) {
|
|
|
|
chunk = state.decoder.write(chunk);
|
|
|
|
if (state.objectMode || chunk.length !== 0)
|
|
|
|
addChunk(stream, state, chunk, false);
|
2016-02-14 18:25:40 +01:00
|
|
|
else
|
2017-05-19 10:07:53 +02:00
|
|
|
maybeReadMore(stream, state);
|
|
|
|
} else {
|
|
|
|
addChunk(stream, state, chunk, false);
|
2016-02-14 18:25:40 +01:00
|
|
|
}
|
2013-07-27 02:05:36 +02:00
|
|
|
}
|
2017-05-19 10:07:53 +02:00
|
|
|
} else if (!addToFront) {
|
|
|
|
state.reading = false;
|
2018-01-17 19:42:38 +01:00
|
|
|
maybeReadMore(stream, state);
|
stream: Fix unshift() race conditions
Fix #5272
The consumption of a readable stream is a dance with 3 partners.
1. The specific stream Author (A)
2. The Stream Base class (B), and
3. The Consumer of the stream (C)
When B calls the _read() method that A implements, it sets a 'reading'
flag, so that parallel calls to _read() can be avoided. When A calls
stream.push(), B knows that it's safe to start calling _read() again.
If the consumer C is some kind of parser that wants in some cases to
pass the source stream off to some other party, but not before "putting
back" some bit of previously consumed data (as in the case of Node's
websocket http upgrade implementation). So, stream.unshift() will
generally *never* be called by A, but *only* called by C.
Prior to this patch, stream.unshift() *also* unset the state.reading
flag, meaning that C could indicate the end of a read, and B would
dutifully fire off another _read() call to A. This is inappropriate.
In the case of fs streams, and other variably-laggy streams that don't
tolerate overlapped _read() calls, this causes big problems.
Also, calling stream.shift() after the 'end' event did not raise any
kind of error, but would cause very strange behavior indeed. Calling it
after the EOF chunk was seen, but before the 'end' event was fired would
also cause weird behavior, and could lead to data being lost, since it
would not emit another 'readable' event.
This change makes it so that:
1. stream.unshift() does *not* set state.reading = false
2. stream.unshift() is allowed up until the 'end' event.
3. unshifting onto a EOF-encountered and zero-length (but not yet
end-emitted) stream will defer the 'end' event until the new data is
consumed.
4. pushing onto a EOF-encountered stream is now an error.
So, if you read(), you have that single tick to safely unshift() data
back into the stream, even if the null chunk was pushed, and the length
was 0.
2013-04-12 00:01:26 +02:00
|
|
|
}
|
2013-02-28 01:56:30 +01:00
|
|
|
}
|
|
|
|
|
2018-05-29 01:47:27 +02:00
|
|
|
// We can push more data if we are below the highWaterMark.
|
|
|
|
// Also, if we have no data yet, we can stand some more bytes.
|
|
|
|
// This is to work around cases where hwm=0, such as the repl.
|
|
|
|
return !state.ended &&
|
|
|
|
(state.length < state.highWaterMark || state.length === 0);
|
2013-02-28 01:56:30 +01:00
|
|
|
}
|
|
|
|
|
2017-05-19 10:07:53 +02:00
|
|
|
function addChunk(stream, state, chunk, addToFront) {
|
|
|
|
if (state.flowing && state.length === 0 && !state.sync) {
|
2018-02-02 01:41:35 +01:00
|
|
|
state.awaitDrain = 0;
|
2017-05-19 10:07:53 +02:00
|
|
|
stream.emit('data', chunk);
|
|
|
|
} else {
|
2019-03-22 03:44:26 +01:00
|
|
|
// Update the buffer info.
|
2017-05-19 10:07:53 +02:00
|
|
|
state.length += state.objectMode ? 1 : chunk.length;
|
|
|
|
if (addToFront)
|
|
|
|
state.buffer.unshift(chunk);
|
|
|
|
else
|
|
|
|
state.buffer.push(chunk);
|
|
|
|
|
|
|
|
if (state.needReadable)
|
|
|
|
emitReadable(stream);
|
|
|
|
}
|
|
|
|
maybeReadMore(stream, state);
|
|
|
|
}
|
|
|
|
|
|
|
|
function chunkInvalid(state, chunk) {
|
2017-01-09 19:05:06 +01:00
|
|
|
if (!Stream._isUint8Array(chunk) &&
|
2017-05-19 10:07:53 +02:00
|
|
|
typeof chunk !== 'string' &&
|
|
|
|
chunk !== undefined &&
|
|
|
|
!state.objectMode) {
|
2019-03-18 15:41:19 +01:00
|
|
|
return new ERR_INVALID_ARG_TYPE(
|
2018-03-19 13:33:46 +01:00
|
|
|
'chunk', ['string', 'Buffer', 'Uint8Array'], chunk);
|
2017-05-19 10:07:53 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-02-28 01:56:30 +01:00
|
|
|
|
2017-05-19 10:07:53 +02:00
|
|
|
Readable.prototype.isPaused = function() {
|
|
|
|
return this._readableState.flowing === false;
|
|
|
|
};
|
|
|
|
|
2019-03-22 03:44:26 +01:00
|
|
|
// Backwards compatibility.
|
2012-10-04 01:52:14 +02:00
|
|
|
Readable.prototype.setEncoding = function(enc) {
|
|
|
|
if (!StringDecoder)
|
|
|
|
StringDecoder = require('string_decoder').StringDecoder;
|
|
|
|
this._readableState.decoder = new StringDecoder(enc);
|
2018-12-10 13:27:32 +01:00
|
|
|
// If setEncoding(null), decoder.encoding equals utf8
|
2018-02-24 15:00:32 +01:00
|
|
|
this._readableState.encoding = this._readableState.decoder.encoding;
|
2013-08-19 19:14:42 +02:00
|
|
|
return this;
|
2012-10-04 01:52:14 +02:00
|
|
|
};
|
|
|
|
|
2015-08-20 22:19:46 +02:00
|
|
|
// Don't raise the hwm > 8MB
|
2015-01-21 17:36:59 +01:00
|
|
|
const MAX_HWM = 0x800000;
|
2015-08-20 22:33:12 +02:00
|
|
|
function computeNewHighWaterMark(n) {
|
2013-03-06 18:55:00 +01:00
|
|
|
if (n >= MAX_HWM) {
|
|
|
|
n = MAX_HWM;
|
|
|
|
} else {
|
2016-05-31 19:03:59 +02:00
|
|
|
// Get the next highest power of 2 to prevent increasing hwm excessively in
|
|
|
|
// tiny amounts
|
2013-03-06 18:55:00 +01:00
|
|
|
n--;
|
2015-08-20 22:29:57 +02:00
|
|
|
n |= n >>> 1;
|
|
|
|
n |= n >>> 2;
|
|
|
|
n |= n >>> 4;
|
|
|
|
n |= n >>> 8;
|
|
|
|
n |= n >>> 16;
|
2013-03-06 18:55:00 +01:00
|
|
|
n++;
|
|
|
|
}
|
|
|
|
return n;
|
|
|
|
}
|
2012-10-03 00:44:50 +02:00
|
|
|
|
2016-05-31 19:03:59 +02:00
|
|
|
// This function is designed to be inlinable, so please take care when making
|
|
|
|
// changes to the function body.
|
2012-10-07 22:12:21 +02:00
|
|
|
function howMuchToRead(n, state) {
|
2016-05-31 19:03:59 +02:00
|
|
|
if (n <= 0 || (state.length === 0 && state.ended))
|
2012-10-07 22:12:21 +02:00
|
|
|
return 0;
|
2013-01-12 05:59:57 +01:00
|
|
|
if (state.objectMode)
|
2016-05-31 19:03:59 +02:00
|
|
|
return 1;
|
2018-02-13 00:56:35 +01:00
|
|
|
if (Number.isNaN(n)) {
|
2016-05-31 19:03:59 +02:00
|
|
|
// Only flow one buffer at a time
|
|
|
|
if (state.flowing && state.length)
|
|
|
|
return state.buffer.head.data.length;
|
2013-02-14 20:26:54 +01:00
|
|
|
else
|
|
|
|
return state.length;
|
|
|
|
}
|
2016-05-31 19:03:59 +02:00
|
|
|
// If we're asking for more than the current hwm, then raise the hwm.
|
2013-03-06 07:09:27 +01:00
|
|
|
if (n > state.highWaterMark)
|
2015-08-20 22:33:12 +02:00
|
|
|
state.highWaterMark = computeNewHighWaterMark(n);
|
2016-05-31 19:03:59 +02:00
|
|
|
if (n <= state.length)
|
|
|
|
return n;
|
|
|
|
// Don't have enough
|
|
|
|
if (!state.ended) {
|
|
|
|
state.needReadable = true;
|
|
|
|
return 0;
|
2012-10-03 00:44:50 +02:00
|
|
|
}
|
2016-05-31 19:03:59 +02:00
|
|
|
return state.length;
|
2012-10-07 22:12:21 +02:00
|
|
|
}
|
2012-10-04 01:52:14 +02:00
|
|
|
|
2018-12-03 17:15:45 +01:00
|
|
|
// You can override either this method, or the async _read(n) below.
|
2012-10-07 22:12:21 +02:00
|
|
|
Readable.prototype.read = function(n) {
|
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.
2013-07-18 03:24:02 +02:00
|
|
|
debug('read', n);
|
2016-05-31 19:03:59 +02:00
|
|
|
n = parseInt(n, 10);
|
2012-10-07 22:12:21 +02:00
|
|
|
var state = this._readableState;
|
|
|
|
var nOrig = n;
|
2012-10-03 00:44:50 +02:00
|
|
|
|
2016-05-31 19:03:59 +02:00
|
|
|
if (n !== 0)
|
2012-11-13 08:32:05 +01:00
|
|
|
state.emittedReadable = false;
|
|
|
|
|
2018-12-10 13:27:32 +01:00
|
|
|
// If we're doing read(0) to trigger a readable event, but we
|
2013-02-12 00:37:50 +01:00
|
|
|
// already have a bunch of data in the buffer, then just trigger
|
|
|
|
// the 'readable' event and move on.
|
|
|
|
if (n === 0 &&
|
|
|
|
state.needReadable &&
|
2018-07-06 01:19:15 +02:00
|
|
|
((state.highWaterMark !== 0 ?
|
|
|
|
state.length >= state.highWaterMark :
|
|
|
|
state.length > 0) ||
|
|
|
|
state.ended)) {
|
2013-07-25 01:05:54 +02:00
|
|
|
debug('read: emitReadable', state.length, state.ended);
|
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.
2013-07-18 03:24:02 +02:00
|
|
|
if (state.length === 0 && state.ended)
|
|
|
|
endReadable(this);
|
|
|
|
else
|
|
|
|
emitReadable(this);
|
2013-02-12 00:37:50 +01:00
|
|
|
return null;
|
|
|
|
}
|
|
|
|
|
2012-10-07 22:12:21 +02:00
|
|
|
n = howMuchToRead(n, state);
|
2012-10-03 00:44:50 +02:00
|
|
|
|
2018-12-10 13:27:32 +01:00
|
|
|
// If we've ended, and we're now clear, then finish it up.
|
2012-10-07 22:12:21 +02:00
|
|
|
if (n === 0 && state.ended) {
|
2013-01-14 20:25:39 +01:00
|
|
|
if (state.length === 0)
|
|
|
|
endReadable(this);
|
2012-10-07 22:12:21 +02:00
|
|
|
return null;
|
|
|
|
}
|
2012-10-03 00:44:50 +02:00
|
|
|
|
2012-10-07 22:12:21 +02:00
|
|
|
// All the actual chunk generation logic needs to be
|
|
|
|
// *below* the call to _read. The reason is that in certain
|
|
|
|
// synthetic stream cases, such as passthrough streams, _read
|
|
|
|
// may be a completely synchronous operation which may change
|
|
|
|
// the state of the read buffer, providing enough data when
|
|
|
|
// before there was *not* enough.
|
|
|
|
//
|
|
|
|
// So, the steps are:
|
|
|
|
// 1. Figure out what the state of things will be after we do
|
|
|
|
// a read from the buffer.
|
|
|
|
//
|
|
|
|
// 2. If that resulting state will trigger a _read, then call _read.
|
|
|
|
// Note that this may be asynchronous, or synchronous. Yes, it is
|
|
|
|
// deeply ugly to write APIs this way, but that still doesn't mean
|
|
|
|
// that the Readable class should behave improperly, as streams are
|
|
|
|
// designed to be sync/async agnostic.
|
|
|
|
// Take note if the _read call is sync or async (ie, if the read call
|
|
|
|
// has returned yet), so that we know whether or not it's safe to emit
|
|
|
|
// 'readable' etc.
|
|
|
|
//
|
|
|
|
// 3. Actually pull the requested chunks out of the buffer and return.
|
|
|
|
|
|
|
|
// if we need a readable event, then we need to do some reading.
|
|
|
|
var doRead = state.needReadable;
|
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.
2013-07-18 03:24:02 +02:00
|
|
|
debug('need readable', doRead);
|
2012-11-13 08:31:25 +01:00
|
|
|
|
2018-12-03 17:15:45 +01:00
|
|
|
// If we currently have less than the highWaterMark, then also read some
|
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.
2013-07-18 03:24:02 +02:00
|
|
|
if (state.length === 0 || state.length - n < state.highWaterMark) {
|
2012-10-07 22:12:21 +02:00
|
|
|
doRead = true;
|
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.
2013-07-18 03:24:02 +02:00
|
|
|
debug('length less than watermark', doRead);
|
|
|
|
}
|
2012-11-13 08:31:25 +01:00
|
|
|
|
2018-12-03 17:15:45 +01:00
|
|
|
// However, if we've ended, then there's no point, and if we're already
|
2012-10-07 22:12:21 +02:00
|
|
|
// reading, then it's unnecessary.
|
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.
2013-07-18 03:24:02 +02:00
|
|
|
if (state.ended || state.reading) {
|
2012-10-07 22:12:21 +02:00
|
|
|
doRead = false;
|
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.
2013-07-18 03:24:02 +02:00
|
|
|
debug('reading or ended', doRead);
|
2016-05-31 19:03:59 +02:00
|
|
|
} else if (doRead) {
|
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.
2013-07-18 03:24:02 +02:00
|
|
|
debug('do read');
|
2012-10-03 00:44:50 +02:00
|
|
|
state.reading = true;
|
2012-10-31 22:30:30 +01:00
|
|
|
state.sync = true;
|
2018-12-03 17:15:45 +01:00
|
|
|
// If the length is currently zero, then we *need* a readable event.
|
2012-12-13 07:03:19 +01:00
|
|
|
if (state.length === 0)
|
|
|
|
state.needReadable = true;
|
2019-03-22 03:44:26 +01:00
|
|
|
// Call internal read method
|
2013-03-06 07:57:15 +01:00
|
|
|
this._read(state.highWaterMark);
|
2012-10-31 22:30:30 +01:00
|
|
|
state.sync = false;
|
2016-05-31 19:03:59 +02:00
|
|
|
// If _read pushed data synchronously, then `reading` will be false,
|
|
|
|
// and we need to re-evaluate how much data we can return to the user.
|
|
|
|
if (!state.reading)
|
|
|
|
n = howMuchToRead(nOrig, state);
|
2012-10-03 00:44:50 +02:00
|
|
|
}
|
|
|
|
|
2012-10-07 22:12:21 +02:00
|
|
|
var ret;
|
|
|
|
if (n > 0)
|
2013-01-12 05:59:57 +01:00
|
|
|
ret = fromList(n, state);
|
2012-10-07 22:12:21 +02:00
|
|
|
else
|
|
|
|
ret = null;
|
|
|
|
|
2015-01-29 02:05:53 +01:00
|
|
|
if (ret === null) {
|
2012-10-07 22:12:21 +02:00
|
|
|
state.needReadable = true;
|
|
|
|
n = 0;
|
2016-05-31 19:03:59 +02:00
|
|
|
} else {
|
|
|
|
state.length -= n;
|
2018-02-02 01:41:35 +01:00
|
|
|
state.awaitDrain = 0;
|
2012-10-07 22:12:21 +02:00
|
|
|
}
|
|
|
|
|
2016-05-31 19:03:59 +02:00
|
|
|
if (state.length === 0) {
|
|
|
|
// If we have nothing in the buffer, then we want to know
|
|
|
|
// as soon as we *do* get something into the buffer.
|
|
|
|
if (!state.ended)
|
|
|
|
state.needReadable = true;
|
2012-12-13 07:03:19 +01:00
|
|
|
|
2016-05-31 19:03:59 +02:00
|
|
|
// If we tried to read() past the EOF, then emit end on the next tick.
|
|
|
|
if (nOrig !== n && state.ended)
|
|
|
|
endReadable(this);
|
|
|
|
}
|
2013-01-16 01:44:29 +01:00
|
|
|
|
2015-01-29 02:05:53 +01:00
|
|
|
if (ret !== null)
|
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.
2013-07-18 03:24:02 +02:00
|
|
|
this.emit('data', ret);
|
2013-07-25 01:05:54 +02:00
|
|
|
|
2012-10-03 00:44:50 +02:00
|
|
|
return ret;
|
|
|
|
};
|
|
|
|
|
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.
2013-03-01 00:32:32 +01:00
|
|
|
function onEofChunk(stream, state) {
|
2019-02-15 17:19:38 +01:00
|
|
|
debug('onEofChunk');
|
2014-10-02 18:00:40 +02:00
|
|
|
if (state.ended) return;
|
|
|
|
if (state.decoder) {
|
2013-02-28 01:56:30 +01:00
|
|
|
var chunk = state.decoder.end();
|
|
|
|
if (chunk && chunk.length) {
|
|
|
|
state.buffer.push(chunk);
|
|
|
|
state.length += state.objectMode ? 1 : chunk.length;
|
|
|
|
}
|
2012-10-31 22:30:30 +01:00
|
|
|
}
|
2013-03-14 14:01:14 +01:00
|
|
|
state.ended = true;
|
2012-10-31 22:30:30 +01:00
|
|
|
|
2019-03-13 22:26:18 +01:00
|
|
|
if (state.sync) {
|
|
|
|
// If we are sync, wait until next tick to emit the data.
|
|
|
|
// Otherwise we risk emitting data in the flow()
|
|
|
|
// the readable code triggers during a read() call
|
|
|
|
emitReadable(stream);
|
|
|
|
} else {
|
|
|
|
// Emit 'readable' now to make sure it gets picked up.
|
|
|
|
state.needReadable = false;
|
|
|
|
state.emittedReadable = true;
|
|
|
|
// We have to emit readable now that we are EOF. Modules
|
|
|
|
// in the ecosystem (e.g. dicer) rely on this event being sync.
|
|
|
|
if (state.ended) {
|
|
|
|
emitReadable_(stream);
|
|
|
|
} else {
|
|
|
|
process.nextTick(emitReadable_, stream);
|
|
|
|
}
|
|
|
|
}
|
2012-10-31 22:30:30 +01:00
|
|
|
}
|
|
|
|
|
stream: Return false from push() more properly
There are cases where a push() call would return true, even though
the thing being pushed was in fact way way larger than the high
water mark, simply because the 'needReadable' was already set, and
would not get unset until nextTick.
In some cases, this could lead to an infinite loop of pushing data
into the buffer, never getting to the 'readable' event which would
unset the needReadable flag.
Fix by splitting up the emitReadable function, so that it always
sets the flag on this tick, even if it defers until nextTick to
actually emit the event.
Also, if we're not ending or already in the process of reading, it
now calls read(0) if we're below the high water mark. Thus, the
highWaterMark value is the intended amount to buffer up to, and it
is smarter about hitting the target.
2013-02-21 23:30:36 +01:00
|
|
|
// Don't emit readable right away in sync mode, because this can trigger
|
|
|
|
// another read() call => stack overflow. This way, it might trigger
|
|
|
|
// a nextTick recursion warning, but that's not so bad.
|
2013-01-24 02:52:45 +01:00
|
|
|
function emitReadable(stream) {
|
|
|
|
var state = stream._readableState;
|
2019-02-15 17:19:38 +01:00
|
|
|
debug('emitReadable', state.needReadable, state.emittedReadable);
|
2013-01-24 02:52:45 +01:00
|
|
|
state.needReadable = false;
|
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.
2013-07-18 03:24:02 +02:00
|
|
|
if (!state.emittedReadable) {
|
|
|
|
debug('emitReadable', state.flowing);
|
|
|
|
state.emittedReadable = true;
|
2018-01-04 18:06:56 +01:00
|
|
|
process.nextTick(emitReadable_, stream);
|
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.
2013-07-18 03:24:02 +02:00
|
|
|
}
|
stream: Return false from push() more properly
There are cases where a push() call would return true, even though
the thing being pushed was in fact way way larger than the high
water mark, simply because the 'needReadable' was already set, and
would not get unset until nextTick.
In some cases, this could lead to an infinite loop of pushing data
into the buffer, never getting to the 'readable' event which would
unset the needReadable flag.
Fix by splitting up the emitReadable function, so that it always
sets the flag on this tick, even if it defers until nextTick to
actually emit the event.
Also, if we're not ending or already in the process of reading, it
now calls read(0) if we're below the high water mark. Thus, the
highWaterMark value is the intended amount to buffer up to, and it
is smarter about hitting the target.
2013-02-21 23:30:36 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
function emitReadable_(stream) {
|
2018-01-04 18:06:56 +01:00
|
|
|
var state = stream._readableState;
|
2018-08-31 06:20:36 +02:00
|
|
|
debug('emitReadable_', state.destroyed, state.length, state.ended);
|
2018-01-25 15:40:10 +01:00
|
|
|
if (!state.destroyed && (state.length || state.ended)) {
|
|
|
|
stream.emit('readable');
|
2019-02-15 17:19:38 +01:00
|
|
|
state.emittedReadable = false;
|
2018-01-25 15:40:10 +01:00
|
|
|
}
|
2018-03-26 14:35:08 +02:00
|
|
|
|
|
|
|
// The stream needs another readable event if
|
|
|
|
// 1. It is not flowing, as the flow mechanism will take
|
|
|
|
// care of it.
|
|
|
|
// 2. It is not ended.
|
|
|
|
// 3. It is below the highWaterMark, so we can schedule
|
|
|
|
// another readable later.
|
|
|
|
state.needReadable =
|
|
|
|
!state.flowing &&
|
|
|
|
!state.ended &&
|
|
|
|
state.length <= state.highWaterMark;
|
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.
2013-07-18 03:24:02 +02:00
|
|
|
flow(stream);
|
2013-02-22 20:24:05 +01:00
|
|
|
}
|
stream: Return false from push() more properly
There are cases where a push() call would return true, even though
the thing being pushed was in fact way way larger than the high
water mark, simply because the 'needReadable' was already set, and
would not get unset until nextTick.
In some cases, this could lead to an infinite loop of pushing data
into the buffer, never getting to the 'readable' event which would
unset the needReadable flag.
Fix by splitting up the emitReadable function, so that it always
sets the flag on this tick, even if it defers until nextTick to
actually emit the event.
Also, if we're not ending or already in the process of reading, it
now calls read(0) if we're below the high water mark. Thus, the
highWaterMark value is the intended amount to buffer up to, and it
is smarter about hitting the target.
2013-02-21 23:30:36 +01:00
|
|
|
|
2013-02-28 01:56:30 +01:00
|
|
|
|
2018-12-03 17:15:45 +01:00
|
|
|
// At this point, the user has presumably seen the 'readable' event,
|
2013-02-28 01:56:30 +01:00
|
|
|
// and called read() to consume some data. that may have triggered
|
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.
2013-03-01 00:32:32 +01:00
|
|
|
// in turn another _read(n) call, in which case reading = true if
|
2013-02-28 01:56:30 +01:00
|
|
|
// it's in progress.
|
|
|
|
// However, if we're not ended, or reading, and the length < hwm,
|
2013-03-08 09:26:53 +01:00
|
|
|
// then go ahead and try to read some more preemptively.
|
2013-02-22 20:24:05 +01:00
|
|
|
function maybeReadMore(stream, state) {
|
2013-03-08 09:26:53 +01:00
|
|
|
if (!state.readingMore) {
|
|
|
|
state.readingMore = true;
|
2015-03-05 22:07:27 +01:00
|
|
|
process.nextTick(maybeReadMore_, stream, state);
|
2013-03-08 09:26:53 +01:00
|
|
|
}
|
2013-02-28 01:56:30 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
function maybeReadMore_(stream, state) {
|
2018-12-09 10:09:01 +01:00
|
|
|
// Attempt to read more data if we should.
|
|
|
|
//
|
|
|
|
// The conditions for reading more data are (one of):
|
|
|
|
// - Not enough data buffered (state.length < state.highWaterMark). The loop
|
|
|
|
// is responsible for filling the buffer with enough data if such data
|
|
|
|
// is available. If highWaterMark is 0 and we are not in the flowing mode
|
|
|
|
// we should _not_ attempt to buffer any extra data. We'll get more data
|
|
|
|
// when the stream consumer calls read() instead.
|
|
|
|
// - No data in the buffer, and the stream is in flowing mode. In this mode
|
|
|
|
// the loop below is responsible for ensuring read() is called. Failing to
|
|
|
|
// call read here would abort the flow and there's no other mechanism for
|
|
|
|
// continuing the flow if the stream consumer has just subscribed to the
|
|
|
|
// 'data' event.
|
|
|
|
//
|
|
|
|
// In addition to the above conditions to keep reading data, the following
|
|
|
|
// conditions prevent the data from being read:
|
|
|
|
// - The stream has ended (state.ended).
|
|
|
|
// - There is already a pending 'read' operation (state.reading). This is a
|
|
|
|
// case where the the stream has called the implementation defined _read()
|
|
|
|
// method, but they are processing the call asynchronously and have _not_
|
|
|
|
// called push() with new data. In this case we skip performing more
|
|
|
|
// read()s. The execution ends in this method again after the _read() ends
|
|
|
|
// up calling push() with more data.
|
2018-01-04 18:06:56 +01:00
|
|
|
while (!state.reading && !state.ended &&
|
2018-12-09 10:09:01 +01:00
|
|
|
(state.length < state.highWaterMark ||
|
|
|
|
(state.flowing && state.length === 0))) {
|
|
|
|
const len = state.length;
|
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.
2013-07-18 03:24:02 +02:00
|
|
|
debug('maybeReadMore read 0');
|
stream: Return false from push() more properly
There are cases where a push() call would return true, even though
the thing being pushed was in fact way way larger than the high
water mark, simply because the 'needReadable' was already set, and
would not get unset until nextTick.
In some cases, this could lead to an infinite loop of pushing data
into the buffer, never getting to the 'readable' event which would
unset the needReadable flag.
Fix by splitting up the emitReadable function, so that it always
sets the flag on this tick, even if it defers until nextTick to
actually emit the event.
Also, if we're not ending or already in the process of reading, it
now calls read(0) if we're below the high water mark. Thus, the
highWaterMark value is the intended amount to buffer up to, and it
is smarter about hitting the target.
2013-02-21 23:30:36 +01:00
|
|
|
stream.read(0);
|
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.
2013-03-09 19:56:17 +01:00
|
|
|
if (len === state.length)
|
2019-03-07 01:03:53 +01:00
|
|
|
// Didn't get any data, stop spinning.
|
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.
2013-03-09 19:56:17 +01:00
|
|
|
break;
|
stream: Return false from push() more properly
There are cases where a push() call would return true, even though
the thing being pushed was in fact way way larger than the high
water mark, simply because the 'needReadable' was already set, and
would not get unset until nextTick.
In some cases, this could lead to an infinite loop of pushing data
into the buffer, never getting to the 'readable' event which would
unset the needReadable flag.
Fix by splitting up the emitReadable function, so that it always
sets the flag on this tick, even if it defers until nextTick to
actually emit the event.
Also, if we're not ending or already in the process of reading, it
now calls read(0) if we're below the high water mark. Thus, the
highWaterMark value is the intended amount to buffer up to, and it
is smarter about hitting the target.
2013-02-21 23:30:36 +01:00
|
|
|
}
|
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.
2013-03-09 19:56:17 +01:00
|
|
|
state.readingMore = false;
|
2013-01-24 02:52:45 +01:00
|
|
|
}
|
|
|
|
|
2018-12-03 17:15:45 +01:00
|
|
|
// Abstract method. to be overridden in specific implementation classes.
|
2012-10-03 00:44:50 +02:00
|
|
|
// call cb(er, data) where data is <= n in length.
|
|
|
|
// for virtual (non-string, non-buffer) streams, "length" is somewhat
|
|
|
|
// arbitrary, and perhaps not very meaningful.
|
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.
2013-03-01 00:32:32 +01:00
|
|
|
Readable.prototype._read = function(n) {
|
2018-08-21 20:05:12 +02:00
|
|
|
errorOrDestroy(this, new ERR_METHOD_NOT_IMPLEMENTED('_read()'));
|
2012-10-03 00:44:50 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
Readable.prototype.pipe = function(dest, pipeOpts) {
|
|
|
|
var src = this;
|
|
|
|
var state = this._readableState;
|
2012-11-17 04:27:41 +01:00
|
|
|
|
|
|
|
switch (state.pipesCount) {
|
|
|
|
case 0:
|
|
|
|
state.pipes = dest;
|
|
|
|
break;
|
|
|
|
case 1:
|
2012-12-06 19:21:22 +01:00
|
|
|
state.pipes = [state.pipes, dest];
|
2012-11-17 04:27:41 +01:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
state.pipes.push(dest);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
state.pipesCount += 1;
|
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.
2013-07-18 03:24:02 +02:00
|
|
|
debug('pipe count=%d opts=%j', state.pipesCount, pipeOpts);
|
2012-10-03 00:44:50 +02:00
|
|
|
|
stream: Don't emit 'end' unless read() called
This solves the problem of calling `readable.pipe(writable)` after the
readable stream has already emitted 'end', as often is the case when
writing simple HTTP proxies.
The spirit of streams2 is that things will work properly, even if you
don't set them up right away on the first tick.
This approach breaks down, however, because pipe()ing from an ended
readable will just do nothing. No more data will ever arrive, and the
writable will hang open forever never being ended.
However, that does not solve the case of adding a `on('end')` listener
after the stream has received the EOF chunk, if it was the first chunk
received (and thus, length was 0, and 'end' got emitted). So, with
this, we defer the 'end' event emission until the read() function is
called.
Also, in pipe(), if the source has emitted 'end' already, we call the
cleanup/onend function on nextTick. Piping from an already-ended stream
is thus the same as piping from a stream that is in the process of
ending.
Updates many tests that were relying on 'end' coming immediately, even
though they never read() from the req.
Fix #4942
2013-03-10 03:05:39 +01:00
|
|
|
var doEnd = (!pipeOpts || pipeOpts.end !== false) &&
|
|
|
|
dest !== process.stdout &&
|
|
|
|
dest !== process.stderr;
|
|
|
|
|
2017-03-16 06:53:35 +01:00
|
|
|
var endFn = doEnd ? onend : unpipe;
|
stream: Don't emit 'end' unless read() called
This solves the problem of calling `readable.pipe(writable)` after the
readable stream has already emitted 'end', as often is the case when
writing simple HTTP proxies.
The spirit of streams2 is that things will work properly, even if you
don't set them up right away on the first tick.
This approach breaks down, however, because pipe()ing from an ended
readable will just do nothing. No more data will ever arrive, and the
writable will hang open forever never being ended.
However, that does not solve the case of adding a `on('end')` listener
after the stream has received the EOF chunk, if it was the first chunk
received (and thus, length was 0, and 'end' got emitted). So, with
this, we defer the 'end' event emission until the read() function is
called.
Also, in pipe(), if the source has emitted 'end' already, we call the
cleanup/onend function on nextTick. Piping from an already-ended stream
is thus the same as piping from a stream that is in the process of
ending.
Updates many tests that were relying on 'end' coming immediately, even
though they never read() from the req.
Fix #4942
2013-03-10 03:05:39 +01:00
|
|
|
if (state.endEmitted)
|
|
|
|
process.nextTick(endFn);
|
|
|
|
else
|
|
|
|
src.once('end', endFn);
|
2013-01-07 15:10:35 +01:00
|
|
|
|
|
|
|
dest.on('unpipe', onunpipe);
|
2017-04-29 20:25:35 +02:00
|
|
|
function onunpipe(readable, unpipeInfo) {
|
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.
2013-07-18 03:24:02 +02:00
|
|
|
debug('onunpipe');
|
|
|
|
if (readable === src) {
|
2017-04-29 20:25:35 +02:00
|
|
|
if (unpipeInfo && unpipeInfo.hasUnpiped === false) {
|
|
|
|
unpipeInfo.hasUnpiped = true;
|
|
|
|
cleanup();
|
|
|
|
}
|
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.
2013-07-18 03:24:02 +02:00
|
|
|
}
|
2012-10-03 00:44:50 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
function onend() {
|
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.
2013-07-18 03:24:02 +02:00
|
|
|
debug('onend');
|
2012-10-03 00:44:50 +02:00
|
|
|
dest.end();
|
|
|
|
}
|
|
|
|
|
2018-12-10 13:27:32 +01:00
|
|
|
// When the dest drains, it reduces the awaitDrain counter
|
2012-11-28 19:46:24 +01:00
|
|
|
// on the source. This would be more elegant with a .once()
|
|
|
|
// handler in flow(), but adding and removing repeatedly is
|
|
|
|
// too slow.
|
|
|
|
var ondrain = pipeOnDrain(src);
|
|
|
|
dest.on('drain', ondrain);
|
2013-01-07 15:10:35 +01:00
|
|
|
|
2015-10-11 20:06:17 +02:00
|
|
|
var cleanedUp = false;
|
2013-01-07 15:10:35 +01:00
|
|
|
function cleanup() {
|
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.
2013-07-18 03:24:02 +02:00
|
|
|
debug('cleanup');
|
2019-01-21 01:22:27 +01:00
|
|
|
// Cleanup event handlers once the pipe is broken
|
2013-02-06 15:45:06 +01:00
|
|
|
dest.removeListener('close', onclose);
|
2013-01-07 15:10:35 +01:00
|
|
|
dest.removeListener('finish', onfinish);
|
|
|
|
dest.removeListener('drain', ondrain);
|
|
|
|
dest.removeListener('error', onerror);
|
|
|
|
dest.removeListener('unpipe', onunpipe);
|
|
|
|
src.removeListener('end', onend);
|
2017-03-16 06:53:35 +01:00
|
|
|
src.removeListener('end', unpipe);
|
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.
2013-07-18 03:24:02 +02:00
|
|
|
src.removeListener('data', ondata);
|
2013-01-07 15:10:35 +01:00
|
|
|
|
2015-10-11 20:06:17 +02:00
|
|
|
cleanedUp = true;
|
|
|
|
|
2018-12-10 13:27:32 +01:00
|
|
|
// If the reader is waiting for a drain event from this
|
2013-01-07 15:10:35 +01:00
|
|
|
// specific writer, then it would cause it to never start
|
|
|
|
// flowing again.
|
|
|
|
// So, if this is awaiting a drain, then we just call it now.
|
|
|
|
// If we don't know, then assume that we are waiting for one.
|
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.
2013-07-18 03:24:02 +02:00
|
|
|
if (state.awaitDrain &&
|
|
|
|
(!dest._writableState || dest._writableState.needDrain))
|
2013-01-07 15:10:35 +01:00
|
|
|
ondrain();
|
|
|
|
}
|
2012-11-28 19:46:24 +01:00
|
|
|
|
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.
2013-07-18 03:24:02 +02:00
|
|
|
src.on('data', ondata);
|
|
|
|
function ondata(chunk) {
|
|
|
|
debug('ondata');
|
|
|
|
var ret = dest.write(chunk);
|
2018-01-04 18:06:56 +01:00
|
|
|
debug('dest.write', ret);
|
2018-02-02 01:41:35 +01:00
|
|
|
if (ret === false) {
|
2015-10-11 20:06:17 +02:00
|
|
|
// If the user unpiped during `dest.write()`, it is possible
|
|
|
|
// to get stuck in a permanently paused state if that write
|
|
|
|
// also returned false.
|
2016-04-03 00:37:49 +02:00
|
|
|
// => Check whether `dest` is still a piping destination.
|
|
|
|
if (((state.pipesCount === 1 && state.pipes === dest) ||
|
2019-03-18 12:31:07 +01:00
|
|
|
(state.pipesCount > 1 && state.pipes.includes(dest))) &&
|
2015-10-11 20:06:17 +02:00
|
|
|
!cleanedUp) {
|
2018-01-20 01:19:05 +01:00
|
|
|
debug('false write response, pause', state.awaitDrain);
|
|
|
|
state.awaitDrain++;
|
2015-10-11 20:06:17 +02:00
|
|
|
}
|
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.
2013-07-18 03:24:02 +02:00
|
|
|
src.pause();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-12-10 13:27:32 +01:00
|
|
|
// If the dest has an error, then stop piping into it.
|
|
|
|
// However, don't suppress the throwing behavior for this.
|
2012-12-22 16:14:42 +01:00
|
|
|
function onerror(er) {
|
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.
2013-07-18 03:24:02 +02:00
|
|
|
debug('onerror', er);
|
2012-11-29 07:09:28 +01:00
|
|
|
unpipe();
|
stream: Throw on 'error' if listeners removed
In this situation:
writable.on('error', handler);
readable.pipe(writable);
writable.removeListener('error', handler);
writable.emit('error', new Error('boom'));
there is actually no error handler, but it doesn't throw, because of the
fix for stream.once('error', handler), in 23d92ec.
Note that simply reverting that change is not valid either, because
otherwise this will emit twice, being handled the first time, and then
throwing the second:
writable.once('error', handler);
readable.pipe(writable);
writable.emit('error', new Error('boom'));
Fix this with a horrible hack to make the stream pipe onerror handler
added before any other userland handlers, so that our handler is not
affected by adding or removing any userland handlers.
Closes #6007.
2013-08-19 16:59:39 +02:00
|
|
|
dest.removeListener('error', onerror);
|
2015-09-02 18:23:49 +02:00
|
|
|
if (EE.listenerCount(dest, 'error') === 0)
|
2018-08-21 20:05:12 +02:00
|
|
|
errorOrDestroy(dest, er);
|
2012-12-22 16:14:42 +01:00
|
|
|
}
|
stream: Throw on 'error' if listeners removed
In this situation:
writable.on('error', handler);
readable.pipe(writable);
writable.removeListener('error', handler);
writable.emit('error', new Error('boom'));
there is actually no error handler, but it doesn't throw, because of the
fix for stream.once('error', handler), in 23d92ec.
Note that simply reverting that change is not valid either, because
otherwise this will emit twice, being handled the first time, and then
throwing the second:
writable.once('error', handler);
readable.pipe(writable);
writable.emit('error', new Error('boom'));
Fix this with a horrible hack to make the stream pipe onerror handler
added before any other userland handlers, so that our handler is not
affected by adding or removing any userland handlers.
Closes #6007.
2013-08-19 16:59:39 +02:00
|
|
|
|
2016-04-04 04:55:22 +02:00
|
|
|
// Make sure our error handler is attached before userland ones.
|
|
|
|
prependListener(dest, 'error', onerror);
|
stream: Throw on 'error' if listeners removed
In this situation:
writable.on('error', handler);
readable.pipe(writable);
writable.removeListener('error', handler);
writable.emit('error', new Error('boom'));
there is actually no error handler, but it doesn't throw, because of the
fix for stream.once('error', handler), in 23d92ec.
Note that simply reverting that change is not valid either, because
otherwise this will emit twice, being handled the first time, and then
throwing the second:
writable.once('error', handler);
readable.pipe(writable);
writable.emit('error', new Error('boom'));
Fix this with a horrible hack to make the stream pipe onerror handler
added before any other userland handlers, so that our handler is not
affected by adding or removing any userland handlers.
Closes #6007.
2013-08-19 16:59:39 +02:00
|
|
|
|
2013-02-06 15:45:06 +01:00
|
|
|
// Both close and finish should trigger unpipe, but only once.
|
|
|
|
function onclose() {
|
|
|
|
dest.removeListener('finish', onfinish);
|
|
|
|
unpipe();
|
|
|
|
}
|
|
|
|
dest.once('close', onclose);
|
2012-12-22 16:14:42 +01:00
|
|
|
function onfinish() {
|
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.
2013-07-18 03:24:02 +02:00
|
|
|
debug('onfinish');
|
2013-02-06 15:45:06 +01:00
|
|
|
dest.removeListener('close', onclose);
|
|
|
|
unpipe();
|
2012-12-22 16:14:42 +01:00
|
|
|
}
|
|
|
|
dest.once('finish', onfinish);
|
2012-11-29 07:09:28 +01:00
|
|
|
|
|
|
|
function unpipe() {
|
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.
2013-07-18 03:24:02 +02:00
|
|
|
debug('unpipe');
|
2012-11-29 07:09:28 +01:00
|
|
|
src.unpipe(dest);
|
|
|
|
}
|
|
|
|
|
2019-03-07 01:03:53 +01:00
|
|
|
// Tell the dest that it's being piped to
|
2012-10-03 00:44:50 +02:00
|
|
|
dest.emit('pipe', src);
|
|
|
|
|
2019-01-21 01:22:27 +01:00
|
|
|
// Start the flow if it hasn't been started already.
|
2012-10-04 02:43:27 +02:00
|
|
|
if (!state.flowing) {
|
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.
2013-07-18 03:24:02 +02:00
|
|
|
debug('pipe resume');
|
|
|
|
src.resume();
|
2012-10-04 02:43:27 +02:00
|
|
|
}
|
2012-10-03 00:44:50 +02:00
|
|
|
|
|
|
|
return dest;
|
|
|
|
};
|
|
|
|
|
2012-11-28 10:25:39 +01:00
|
|
|
function pipeOnDrain(src) {
|
2018-07-11 12:38:52 +02:00
|
|
|
return function pipeOnDrainFunctionResult() {
|
2012-11-28 10:25:39 +01:00
|
|
|
var state = src._readableState;
|
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.
2013-07-18 03:24:02 +02:00
|
|
|
debug('pipeOnDrain', state.awaitDrain);
|
|
|
|
if (state.awaitDrain)
|
|
|
|
state.awaitDrain--;
|
2015-09-02 18:23:49 +02:00
|
|
|
if (state.awaitDrain === 0 && EE.listenerCount(src, 'data')) {
|
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.
2013-07-18 03:24:02 +02:00
|
|
|
state.flowing = true;
|
2012-11-28 10:25:39 +01:00
|
|
|
flow(src);
|
2012-11-17 04:27:41 +01:00
|
|
|
}
|
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.
2013-07-18 03:24:02 +02:00
|
|
|
};
|
2012-11-28 03:20:16 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2012-10-03 00:44:50 +02:00
|
|
|
Readable.prototype.unpipe = function(dest) {
|
|
|
|
var state = this._readableState;
|
2017-04-29 20:25:35 +02:00
|
|
|
var unpipeInfo = { hasUnpiped: false };
|
2012-11-17 04:27:41 +01:00
|
|
|
|
2019-01-21 01:22:27 +01:00
|
|
|
// If we're not piping anywhere, then do nothing.
|
2012-11-17 04:27:41 +01:00
|
|
|
if (state.pipesCount === 0)
|
|
|
|
return this;
|
|
|
|
|
2019-01-21 01:22:27 +01:00
|
|
|
// Just one destination. most common case.
|
2012-11-17 04:27:41 +01:00
|
|
|
if (state.pipesCount === 1) {
|
2019-01-21 01:22:27 +01:00
|
|
|
// Passed in one, but it's not the right one.
|
2012-11-17 04:27:41 +01:00
|
|
|
if (dest && dest !== state.pipes)
|
|
|
|
return this;
|
|
|
|
|
|
|
|
if (!dest)
|
|
|
|
dest = state.pipes;
|
|
|
|
|
|
|
|
// got a match.
|
|
|
|
state.pipes = null;
|
|
|
|
state.pipesCount = 0;
|
2013-01-12 05:59:57 +01:00
|
|
|
state.flowing = false;
|
2012-11-17 04:27:41 +01:00
|
|
|
if (dest)
|
2017-04-29 20:25:35 +02:00
|
|
|
dest.emit('unpipe', this, unpipeInfo);
|
2012-11-17 04:27:41 +01:00
|
|
|
return this;
|
2012-10-03 00:44:50 +02:00
|
|
|
}
|
2012-11-17 04:27:41 +01:00
|
|
|
|
2019-03-07 01:03:53 +01:00
|
|
|
// Slow case with multiple pipe destinations.
|
2012-11-17 04:27:41 +01:00
|
|
|
|
|
|
|
if (!dest) {
|
|
|
|
// remove all.
|
|
|
|
var dests = state.pipes;
|
|
|
|
var len = state.pipesCount;
|
|
|
|
state.pipes = null;
|
|
|
|
state.pipesCount = 0;
|
2013-01-12 05:59:57 +01:00
|
|
|
state.flowing = false;
|
2012-11-17 04:27:41 +01:00
|
|
|
|
2016-10-01 00:31:47 +02:00
|
|
|
for (var i = 0; i < len; i++)
|
2018-01-20 04:06:26 +01:00
|
|
|
dests[i].emit('unpipe', this, { hasUnpiped: false });
|
2012-11-17 04:27:41 +01:00
|
|
|
return this;
|
|
|
|
}
|
|
|
|
|
2019-03-22 03:44:26 +01:00
|
|
|
// Try to find the right one.
|
2017-04-24 08:20:38 +02:00
|
|
|
var index = state.pipes.indexOf(dest);
|
2016-10-01 00:31:47 +02:00
|
|
|
if (index === -1)
|
2012-11-17 04:27:41 +01:00
|
|
|
return this;
|
|
|
|
|
2016-10-18 22:30:03 +02:00
|
|
|
state.pipes.splice(index, 1);
|
2012-11-17 04:27:41 +01:00
|
|
|
state.pipesCount -= 1;
|
|
|
|
if (state.pipesCount === 1)
|
|
|
|
state.pipes = state.pipes[0];
|
|
|
|
|
2017-04-29 20:25:35 +02:00
|
|
|
dest.emit('unpipe', this, unpipeInfo);
|
2012-11-17 04:27:41 +01:00
|
|
|
|
2012-10-03 00:44:50 +02:00
|
|
|
return this;
|
|
|
|
};
|
|
|
|
|
2019-01-21 01:22:27 +01:00
|
|
|
// Set up data events if they are asked for
|
2013-03-03 01:03:22 +01:00
|
|
|
// Ensure readable listeners eventually get something
|
2013-01-09 03:17:06 +01:00
|
|
|
Readable.prototype.on = function(ev, fn) {
|
2016-05-31 19:03:59 +02:00
|
|
|
const res = Stream.prototype.on.call(this, ev, fn);
|
2018-02-26 09:24:30 +01:00
|
|
|
const state = this._readableState;
|
2016-05-31 19:03:59 +02:00
|
|
|
|
|
|
|
if (ev === 'data') {
|
2018-12-10 13:27:32 +01:00
|
|
|
// Update readableListening so that resume() may be a no-op
|
2018-02-26 09:24:30 +01:00
|
|
|
// a few lines down. This is needed to support once('readable').
|
|
|
|
state.readableListening = this.listenerCount('readable') > 0;
|
|
|
|
|
|
|
|
// Try start flowing on next tick if stream isn't explicitly paused
|
|
|
|
if (state.flowing !== false)
|
2016-05-31 19:03:59 +02:00
|
|
|
this.resume();
|
|
|
|
} else if (ev === 'readable') {
|
|
|
|
if (!state.endEmitted && !state.readableListening) {
|
|
|
|
state.readableListening = state.needReadable = true;
|
2018-08-09 14:02:33 +02:00
|
|
|
state.flowing = false;
|
2013-03-26 22:42:56 +01:00
|
|
|
state.emittedReadable = false;
|
2018-07-06 01:19:15 +02:00
|
|
|
debug('on readable', state.length, state.reading);
|
2018-02-26 09:24:30 +01:00
|
|
|
if (state.length) {
|
2016-08-17 09:53:48 +02:00
|
|
|
emitReadable(this);
|
2018-02-26 09:24:30 +01:00
|
|
|
} else if (!state.reading) {
|
|
|
|
process.nextTick(nReadingNextTick, this);
|
2013-03-26 22:42:56 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2013-03-03 01:03:22 +01:00
|
|
|
|
2013-01-08 18:56:55 +01:00
|
|
|
return res;
|
2012-10-03 00:44:50 +02:00
|
|
|
};
|
|
|
|
Readable.prototype.addListener = Readable.prototype.on;
|
|
|
|
|
2018-02-26 09:24:30 +01:00
|
|
|
Readable.prototype.removeListener = function(ev, fn) {
|
|
|
|
const res = Stream.prototype.removeListener.call(this, ev, fn);
|
|
|
|
|
|
|
|
if (ev === 'readable') {
|
|
|
|
// We need to check if there is someone still listening to
|
2018-05-20 12:13:03 +02:00
|
|
|
// readable and reset the state. However this needs to happen
|
2018-02-26 09:24:30 +01:00
|
|
|
// after readable has been emitted but before I/O (nextTick) to
|
|
|
|
// support once('readable', fn) cycles. This means that calling
|
|
|
|
// resume within the same tick will have no
|
|
|
|
// effect.
|
|
|
|
process.nextTick(updateReadableListening, this);
|
|
|
|
}
|
|
|
|
|
|
|
|
return res;
|
|
|
|
};
|
|
|
|
|
|
|
|
Readable.prototype.removeAllListeners = function(ev) {
|
2018-05-24 09:17:17 +02:00
|
|
|
const res = Stream.prototype.removeAllListeners.apply(this, arguments);
|
2018-02-26 09:24:30 +01:00
|
|
|
|
|
|
|
if (ev === 'readable' || ev === undefined) {
|
|
|
|
// We need to check if there is someone still listening to
|
2018-05-20 12:13:03 +02:00
|
|
|
// readable and reset the state. However this needs to happen
|
2018-02-26 09:24:30 +01:00
|
|
|
// after readable has been emitted but before I/O (nextTick) to
|
|
|
|
// support once('readable', fn) cycles. This means that calling
|
|
|
|
// resume within the same tick will have no
|
|
|
|
// effect.
|
|
|
|
process.nextTick(updateReadableListening, this);
|
|
|
|
}
|
|
|
|
|
|
|
|
return res;
|
|
|
|
};
|
|
|
|
|
|
|
|
function updateReadableListening(self) {
|
2018-11-14 17:23:28 +01:00
|
|
|
const state = self._readableState;
|
|
|
|
state.readableListening = self.listenerCount('readable') > 0;
|
2018-08-09 14:02:33 +02:00
|
|
|
|
2018-11-14 17:23:28 +01:00
|
|
|
if (state.resumeScheduled && !state.paused) {
|
2019-01-21 01:22:27 +01:00
|
|
|
// Flowing needs to be set to true now, otherwise
|
2018-11-14 17:23:28 +01:00
|
|
|
// the upcoming resume will not flow.
|
|
|
|
state.flowing = true;
|
|
|
|
|
2019-03-07 01:03:53 +01:00
|
|
|
// Crude way to check if we should resume
|
2018-11-14 17:23:28 +01:00
|
|
|
} else if (self.listenerCount('data') > 0) {
|
2018-08-09 14:02:33 +02:00
|
|
|
self.resume();
|
|
|
|
}
|
2018-02-26 09:24:30 +01:00
|
|
|
}
|
|
|
|
|
2015-03-05 22:07:27 +01:00
|
|
|
function nReadingNextTick(self) {
|
|
|
|
debug('readable nexttick read 0');
|
|
|
|
self.read(0);
|
|
|
|
}
|
|
|
|
|
2012-10-03 00:44:50 +02:00
|
|
|
// pause() and resume() are remnants of the legacy readable stream API
|
|
|
|
// If the user uses them, then switch into old mode.
|
|
|
|
Readable.prototype.resume = function() {
|
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.
2013-07-18 03:24:02 +02:00
|
|
|
var state = this._readableState;
|
|
|
|
if (!state.flowing) {
|
|
|
|
debug('resume');
|
2019-01-21 01:22:27 +01:00
|
|
|
// We flow only if there is no one listening
|
2018-08-09 14:02:33 +02:00
|
|
|
// for readable, but we still have to call
|
|
|
|
// resume()
|
2018-02-26 09:24:30 +01:00
|
|
|
state.flowing = !state.readableListening;
|
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.
2013-07-18 03:24:02 +02:00
|
|
|
resume(this, state);
|
|
|
|
}
|
2018-11-14 17:23:28 +01:00
|
|
|
state.paused = false;
|
2013-08-28 03:59:58 +02:00
|
|
|
return this;
|
2012-10-03 00:44:50 +02:00
|
|
|
};
|
|
|
|
|
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.
2013-07-18 03:24:02 +02:00
|
|
|
function resume(stream, state) {
|
|
|
|
if (!state.resumeScheduled) {
|
|
|
|
state.resumeScheduled = true;
|
2015-03-05 22:07:27 +01:00
|
|
|
process.nextTick(resume_, stream, state);
|
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.
2013-07-18 03:24:02 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
function resume_(stream, state) {
|
2018-01-04 18:06:56 +01:00
|
|
|
debug('resume', state.reading);
|
2014-06-11 01:36:04 +02:00
|
|
|
if (!state.reading) {
|
|
|
|
stream.read(0);
|
|
|
|
}
|
2012-10-03 00:44:50 +02:00
|
|
|
|
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.
2013-07-18 03:24:02 +02:00
|
|
|
state.resumeScheduled = false;
|
|
|
|
stream.emit('resume');
|
|
|
|
flow(stream);
|
|
|
|
if (state.flowing && !state.reading)
|
|
|
|
stream.read(0);
|
|
|
|
}
|
|
|
|
|
2012-10-03 00:44:50 +02:00
|
|
|
Readable.prototype.pause = function() {
|
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.
2013-07-18 03:24:02 +02:00
|
|
|
debug('call pause flowing=%j', this._readableState.flowing);
|
2018-03-02 03:44:18 +01:00
|
|
|
if (this._readableState.flowing !== false) {
|
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.
2013-07-18 03:24:02 +02:00
|
|
|
debug('pause');
|
|
|
|
this._readableState.flowing = false;
|
2016-03-29 15:09:27 +02:00
|
|
|
this.emit('pause');
|
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.
2013-07-18 03:24:02 +02:00
|
|
|
}
|
2018-11-14 17:23:28 +01:00
|
|
|
this._readableState.paused = true;
|
2013-08-28 03:59:58 +02:00
|
|
|
return this;
|
2012-10-03 00:44:50 +02:00
|
|
|
};
|
|
|
|
|
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.
2013-07-18 03:24:02 +02:00
|
|
|
function flow(stream) {
|
2016-05-31 19:03:59 +02:00
|
|
|
const state = stream._readableState;
|
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.
2013-07-18 03:24:02 +02:00
|
|
|
debug('flow', state.flowing);
|
2016-05-31 19:03:59 +02:00
|
|
|
while (state.flowing && stream.read() !== null);
|
2012-10-03 00:44:50 +02:00
|
|
|
}
|
|
|
|
|
2018-12-10 13:27:32 +01:00
|
|
|
// Wrap an old-style stream as the async data source.
|
2012-10-03 00:44:50 +02:00
|
|
|
// This is *not* part of the readable stream interface.
|
|
|
|
// It is an ugly unfortunate mess of history.
|
|
|
|
Readable.prototype.wrap = function(stream) {
|
|
|
|
var state = this._readableState;
|
|
|
|
var paused = false;
|
|
|
|
|
2017-11-10 11:34:07 +01:00
|
|
|
stream.on('end', () => {
|
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.
2013-07-18 03:24:02 +02:00
|
|
|
debug('wrapped end');
|
2013-03-14 14:01:14 +01:00
|
|
|
if (state.decoder && !state.ended) {
|
2012-10-12 20:45:17 +02:00
|
|
|
var chunk = state.decoder.end();
|
2013-01-08 04:40:08 +01:00
|
|
|
if (chunk && chunk.length)
|
2017-11-10 11:34:07 +01:00
|
|
|
this.push(chunk);
|
2012-10-12 20:45:17 +02:00
|
|
|
}
|
|
|
|
|
2017-11-10 11:34:07 +01:00
|
|
|
this.push(null);
|
2012-11-17 05:24:14 +01:00
|
|
|
});
|
2012-10-03 00:44:50 +02:00
|
|
|
|
2017-11-10 11:34:07 +01:00
|
|
|
stream.on('data', (chunk) => {
|
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.
2013-07-18 03:24:02 +02:00
|
|
|
debug('wrapped data');
|
2012-10-12 20:45:17 +02:00
|
|
|
if (state.decoder)
|
|
|
|
chunk = state.decoder.write(chunk);
|
2014-06-09 03:58:53 +02:00
|
|
|
|
2019-01-21 01:22:27 +01:00
|
|
|
// Don't skip over falsy values in objectMode
|
2014-06-09 03:58:53 +02:00
|
|
|
if (state.objectMode && (chunk === null || chunk === undefined))
|
|
|
|
return;
|
|
|
|
else if (!state.objectMode && (!chunk || !chunk.length))
|
2012-10-12 20:45:17 +02:00
|
|
|
return;
|
|
|
|
|
2017-11-10 11:34:07 +01:00
|
|
|
var ret = this.push(chunk);
|
2013-01-08 04:40:08 +01:00
|
|
|
if (!ret) {
|
2012-10-03 00:44:50 +02:00
|
|
|
paused = true;
|
|
|
|
stream.pause();
|
|
|
|
}
|
2012-11-17 05:24:14 +01:00
|
|
|
});
|
2012-10-03 00:44:50 +02:00
|
|
|
|
2019-03-22 03:44:26 +01:00
|
|
|
// Proxy all the other methods. Important when wrapping filters and duplexes.
|
2012-10-03 00:44:50 +02:00
|
|
|
for (var i in stream) {
|
2015-01-29 02:05:53 +01:00
|
|
|
if (this[i] === undefined && typeof stream[i] === 'function') {
|
2018-07-11 12:38:52 +02:00
|
|
|
this[i] = function methodWrap(method) {
|
|
|
|
return function methodWrapReturnFunction() {
|
2016-07-09 02:17:47 +02:00
|
|
|
return stream[method].apply(stream, arguments);
|
|
|
|
};
|
|
|
|
}(i);
|
2012-10-03 00:44:50 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-03-07 01:03:53 +01:00
|
|
|
// Proxy certain important events.
|
2017-02-26 07:16:57 +01:00
|
|
|
for (var n = 0; n < kProxyEvents.length; n++) {
|
2017-11-10 11:34:07 +01:00
|
|
|
stream.on(kProxyEvents[n], this.emit.bind(this, kProxyEvents[n]));
|
2017-02-26 07:16:57 +01:00
|
|
|
}
|
2012-10-03 00:44:50 +02:00
|
|
|
|
2018-12-10 13:27:32 +01:00
|
|
|
// When we try to consume some more bytes, simply unpause the
|
2013-01-08 04:40:08 +01:00
|
|
|
// underlying stream.
|
2017-11-10 11:34:07 +01:00
|
|
|
this._read = (n) => {
|
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.
2013-07-18 03:24:02 +02:00
|
|
|
debug('wrapped _read', n);
|
2013-01-08 04:40:08 +01:00
|
|
|
if (paused) {
|
2012-10-03 00:44:50 +02:00
|
|
|
paused = false;
|
2013-03-15 00:43:19 +01:00
|
|
|
stream.resume();
|
2012-10-03 00:44:50 +02:00
|
|
|
}
|
|
|
|
};
|
2013-03-15 00:43:19 +01:00
|
|
|
|
2017-11-10 11:34:07 +01:00
|
|
|
return this;
|
2012-10-03 00:44:50 +02:00
|
|
|
};
|
|
|
|
|
2017-12-19 13:33:31 +01:00
|
|
|
Readable.prototype[Symbol.asyncIterator] = function() {
|
|
|
|
emitExperimentalWarning('Readable[Symbol.asyncIterator]');
|
2018-09-23 22:10:12 +02:00
|
|
|
if (createReadableStreamAsyncIterator === undefined) {
|
|
|
|
createReadableStreamAsyncIterator =
|
|
|
|
require('internal/streams/async_iterator');
|
|
|
|
}
|
|
|
|
return createReadableStreamAsyncIterator(this);
|
2017-12-19 13:33:31 +01:00
|
|
|
};
|
|
|
|
|
2017-05-05 15:57:57 +02:00
|
|
|
Object.defineProperty(Readable.prototype, 'readableHighWaterMark', {
|
2018-12-10 13:27:32 +01:00
|
|
|
// Making it explicit this property is not enumerable
|
2017-05-05 15:57:57 +02:00
|
|
|
// because otherwise some prototype manipulation in
|
|
|
|
// userland will fail
|
|
|
|
enumerable: false,
|
|
|
|
get: function() {
|
|
|
|
return this._readableState.highWaterMark;
|
|
|
|
}
|
|
|
|
});
|
2012-10-03 00:44:50 +02:00
|
|
|
|
2017-05-16 17:08:49 +02:00
|
|
|
Object.defineProperty(Readable.prototype, 'readableBuffer', {
|
2018-12-10 13:27:32 +01:00
|
|
|
// Making it explicit this property is not enumerable
|
2017-05-16 17:08:49 +02:00
|
|
|
// because otherwise some prototype manipulation in
|
|
|
|
// userland will fail
|
|
|
|
enumerable: false,
|
|
|
|
get: function() {
|
|
|
|
return this._readableState && this._readableState.buffer;
|
|
|
|
}
|
|
|
|
});
|
|
|
|
|
|
|
|
Object.defineProperty(Readable.prototype, 'readableFlowing', {
|
2018-12-10 13:27:32 +01:00
|
|
|
// Making it explicit this property is not enumerable
|
2017-05-16 17:08:49 +02:00
|
|
|
// because otherwise some prototype manipulation in
|
|
|
|
// userland will fail
|
|
|
|
enumerable: false,
|
|
|
|
get: function() {
|
|
|
|
return this._readableState.flowing;
|
|
|
|
},
|
|
|
|
set: function(state) {
|
|
|
|
if (this._readableState) {
|
|
|
|
this._readableState.flowing = state;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
});
|
|
|
|
|
2019-03-07 01:03:53 +01:00
|
|
|
// Exposed for testing purposes only.
|
2012-10-03 00:44:50 +02:00
|
|
|
Readable._fromList = fromList;
|
|
|
|
|
2017-05-05 14:42:21 +02:00
|
|
|
Object.defineProperty(Readable.prototype, 'readableLength', {
|
2018-12-10 13:27:32 +01:00
|
|
|
// Making it explicit this property is not enumerable
|
2017-05-05 14:42:21 +02:00
|
|
|
// because otherwise some prototype manipulation in
|
|
|
|
// userland will fail
|
|
|
|
enumerable: false,
|
|
|
|
get() {
|
|
|
|
return this._readableState.length;
|
|
|
|
}
|
|
|
|
});
|
|
|
|
|
2012-10-03 00:44:50 +02:00
|
|
|
// Pluck off n bytes from an array of buffers.
|
|
|
|
// Length is the combined lengths of all the buffers in the list.
|
2016-05-31 19:03:59 +02:00
|
|
|
// This function is designed to be inlinable, so please take care when making
|
|
|
|
// changes to the function body.
|
2013-01-12 05:59:57 +01:00
|
|
|
function fromList(n, state) {
|
2016-05-31 19:03:59 +02:00
|
|
|
// nothing buffered
|
|
|
|
if (state.length === 0)
|
|
|
|
return null;
|
|
|
|
|
2012-10-03 00:44:50 +02:00
|
|
|
var ret;
|
2016-05-31 19:03:59 +02:00
|
|
|
if (state.objectMode)
|
|
|
|
ret = state.buffer.shift();
|
|
|
|
else if (!n || n >= state.length) {
|
2019-03-07 01:03:53 +01:00
|
|
|
// Read it all, truncate the list
|
2016-05-31 19:03:59 +02:00
|
|
|
if (state.decoder)
|
|
|
|
ret = state.buffer.join('');
|
|
|
|
else if (state.buffer.length === 1)
|
2018-01-24 18:45:51 +01:00
|
|
|
ret = state.buffer.first();
|
2016-05-31 19:03:59 +02:00
|
|
|
else
|
|
|
|
ret = state.buffer.concat(state.length);
|
|
|
|
state.buffer.clear();
|
|
|
|
} else {
|
|
|
|
// read part of list
|
2018-01-24 18:45:51 +01:00
|
|
|
ret = state.buffer.consume(n, state.decoder);
|
2016-05-31 19:03:59 +02:00
|
|
|
}
|
2012-10-03 00:44:50 +02:00
|
|
|
|
2016-05-31 19:03:59 +02:00
|
|
|
return ret;
|
|
|
|
}
|
2012-10-03 00:44:50 +02:00
|
|
|
|
2012-10-04 01:52:14 +02:00
|
|
|
function endReadable(stream) {
|
|
|
|
var state = stream._readableState;
|
2013-01-14 20:25:39 +01:00
|
|
|
|
2018-05-01 06:29:16 +02:00
|
|
|
debug('endReadable', state.endEmitted);
|
|
|
|
if (!state.endEmitted) {
|
stream: Don't emit 'end' unless read() called
This solves the problem of calling `readable.pipe(writable)` after the
readable stream has already emitted 'end', as often is the case when
writing simple HTTP proxies.
The spirit of streams2 is that things will work properly, even if you
don't set them up right away on the first tick.
This approach breaks down, however, because pipe()ing from an ended
readable will just do nothing. No more data will ever arrive, and the
writable will hang open forever never being ended.
However, that does not solve the case of adding a `on('end')` listener
after the stream has received the EOF chunk, if it was the first chunk
received (and thus, length was 0, and 'end' got emitted). So, with
this, we defer the 'end' event emission until the read() function is
called.
Also, in pipe(), if the source has emitted 'end' already, we call the
cleanup/onend function on nextTick. Piping from an already-ended stream
is thus the same as piping from a stream that is in the process of
ending.
Updates many tests that were relying on 'end' coming immediately, even
though they never read() from the req.
Fix #4942
2013-03-10 03:05:39 +01:00
|
|
|
state.ended = true;
|
2015-03-05 22:07:27 +01:00
|
|
|
process.nextTick(endReadableNT, state, stream);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
function endReadableNT(state, stream) {
|
2018-05-01 06:29:16 +02:00
|
|
|
debug('endReadableNT', state.endEmitted, state.length);
|
2018-01-04 18:06:56 +01:00
|
|
|
|
2015-03-05 22:07:27 +01:00
|
|
|
// Check that we didn't get one last unshift.
|
|
|
|
if (!state.endEmitted && state.length === 0) {
|
2018-05-01 06:29:16 +02:00
|
|
|
state.endEmitted = true;
|
2015-03-05 22:07:27 +01:00
|
|
|
stream.readable = false;
|
2018-05-01 06:29:16 +02:00
|
|
|
stream.emit('end');
|
2018-08-21 20:05:12 +02:00
|
|
|
|
|
|
|
if (state.autoDestroy) {
|
|
|
|
// In case of duplex streams we need a way to detect
|
|
|
|
// if the writable side is ready for autoDestroy as well
|
|
|
|
const wState = stream._writableState;
|
|
|
|
if (!wState || (wState.autoDestroy && wState.finished)) {
|
|
|
|
stream.destroy();
|
|
|
|
}
|
|
|
|
}
|
stream: Don't emit 'end' unless read() called
This solves the problem of calling `readable.pipe(writable)` after the
readable stream has already emitted 'end', as often is the case when
writing simple HTTP proxies.
The spirit of streams2 is that things will work properly, even if you
don't set them up right away on the first tick.
This approach breaks down, however, because pipe()ing from an ended
readable will just do nothing. No more data will ever arrive, and the
writable will hang open forever never being ended.
However, that does not solve the case of adding a `on('end')` listener
after the stream has received the EOF chunk, if it was the first chunk
received (and thus, length was 0, and 'end' got emitted). So, with
this, we defer the 'end' event emission until the read() function is
called.
Also, in pipe(), if the source has emitted 'end' already, we call the
cleanup/onend function on nextTick. Piping from an already-ended stream
is thus the same as piping from a stream that is in the process of
ending.
Updates many tests that were relying on 'end' coming immediately, even
though they never read() from the req.
Fix #4942
2013-03-10 03:05:39 +01:00
|
|
|
}
|
2012-10-04 01:52:14 +02:00
|
|
|
}
|