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

8514 Commits

131 Branches

446 Tags

325 MiB

Tree: 5453619eb2

Commit Graph

Author SHA1 Message Date

Author	SHA1	Message	Date
isaacs	88644eaa2d	stream: There is no _read cb, there is only push This makes it so that `stream.push(chunk)` is the only way to signal the end of reading, removing the confusing disparity between the callback-style _read method, and the fact that most real-world streams do not have a 1:1 corollation between the "please give me data" event, and the actual arrival of a chunk of data. It is still possible, of course, to implement a `CallbackReadable` on top of this. Simply provide a method like this as the callback: function readCallback(er, chunk) { if (er) stream.emit('error', er); else stream.push(chunk); } However, only fs streams actually would behave in this way, so it makes not a lot of sense to make TCP, TLS, HTTP, and all the rest have to bend into this uncomfortable paradigm.	12 years ago
isaacs	a6c18472cd	stream: Don't stop reading on zero-length decoded output Fixes regression introduced in `7e1cf84c9e`	12 years ago
isaacs	7e1cf84c9e	stream: Don't signal EOF on '' or Buffer(0) Those values, if passed to the _read() cb, will not signal an EOF. Only null or undefined will mark the end of data, and trigger the end event. However, great care must be taken if you are returning an empty string or buffer! There must be some other thing somewhere that will trigger a read() call, because there will never be a readable event fired later. This is in preparation for CryptoStreams being ported to streams2, where it is safe to simply stop reading, because the crypto cycle process will cause it to read(0) again at some future date.	12 years ago

isaacs

88644eaa2d

stream: There is no _read cb, there is only push

This makes it so that `stream.push(chunk)` is the only way to signal the
end of reading, removing the confusing disparity between the
callback-style _read method, and the fact that most real-world streams
do not have a 1:1 corollation between the "please give me data" event,
and the actual arrival of a chunk of data.

It is still possible, of course, to implement a `CallbackReadable` on
top of this.  Simply provide a method like this as the callback:

    function readCallback(er, chunk) {
      if (er)
        stream.emit('error', er);
      else
        stream.push(chunk);
    }

However, *only* fs streams actually would behave in this way, so it
makes not a lot of sense to make TCP, TLS, HTTP, and all the rest have
to bend into this uncomfortable paradigm.

12 years ago

isaacs

a6c18472cd

stream: Don't stop reading on zero-length decoded output

Fixes regression introduced in 7e1cf84c9e

12 years ago

isaacs

7e1cf84c9e

stream: Don't signal EOF on '' or Buffer(0)

Those values, if passed to the _read() cb, will not signal an EOF.  Only
null or undefined will mark the end of data, and trigger the end event.

However, great care must be taken if you are returning an empty string
or buffer!  There must be some other thing somewhere that will trigger
a read() call, because there will never be a readable event fired later.

This is in preparation for CryptoStreams being ported to streams2, where
it is safe to simply stop reading, because the crypto cycle process will
cause it to read(0) again at some future date.

12 years ago

3 Commits (5453619eb2a3bb3e5cae1c1379e3985c724e12c6)