mirror of
https://github.com/nodejs/node.git
synced 2024-12-01 16:10:02 +01:00
eafa902632
In cases where a stream may have data added to the read queue before the user adds a 'readable' event, there is never any indication that it's time to start reading. True, there's already data there, which the user would get if they checked However, as we use 'readable' event listening as the signal to start the flow of data with a read(0) call internally, we ought to trigger the same effect (ie, emitting a 'readable' event) even if the 'readable' listener is added after the first emission. To avoid confusing weirdness, only the *first* 'readable' event listener is granted this privileged status. After we've started the flow (or, alerted the consumer that the flow has started) we don't need to start it again. At that point, it's the consumer's responsibility to consume the stream. Closes #5141 |
||
---|---|---|
.. | ||
_debugger.js | ||
_linklist.js | ||
_stream_duplex.js | ||
_stream_passthrough.js | ||
_stream_readable.js | ||
_stream_transform.js | ||
_stream_writable.js | ||
assert.js | ||
buffer.js | ||
child_process.js | ||
cluster.js | ||
console.js | ||
constants.js | ||
crypto.js | ||
dgram.js | ||
dns.js | ||
domain.js | ||
events.js | ||
freelist.js | ||
fs.js | ||
http.js | ||
https.js | ||
module.js | ||
net.js | ||
os.js | ||
path.js | ||
punycode.js | ||
querystring.js | ||
readline.js | ||
repl.js | ||
stream.js | ||
string_decoder.js | ||
sys.js | ||
timers.js | ||
tls.js | ||
tty.js | ||
url.js | ||
util.js | ||
vm.js | ||
zlib.js |