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

7982 Commits

131 Branches

446 Tags

325 MiB

Tree: fc22986023

Commit Graph

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
Raynos	444bbd4fa7	streams: Support objects other than Buffers We detect for non-string and non-buffer values in onread and turn the stream into an "objectMode" stream. If we are in "objectMode" mode then howMuchToRead will always return 1, state.length will always have 1 appended to it when there is a new item and fromList always takes the first value from the list. This means that for object streams, the n in read(n) is ignored and read() will always return a single value Fixed a bug with unpipe where the pipe would break because the flowing state was not reset to false. Fixed a bug with sync cb(null, null) in _read which would forget to end the readable stream	12 years ago
isaacs	9b1b85490b	streams2: Tests of new interfaces	13 years ago

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

Raynos

444bbd4fa7

streams: Support objects other than Buffers

We detect for non-string and non-buffer values in onread and
turn the stream into an "objectMode" stream.

If we are in "objectMode" mode then howMuchToRead will
always return 1, state.length will always have 1 appended
to it when there is a new item and fromList always takes
the first value from the list.

This means that for object streams, the n in read(n) is
ignored and read() will always return a single value

Fixed a bug with unpipe where the pipe would break because
the flowing state was not reset to false.

Fixed a bug with sync cb(null, null) in _read which would
forget to end the readable stream

12 years ago

isaacs

9b1b85490b

streams2: Tests of new interfaces

13 years ago

3 Commits (fc2298602323530bda9efa75f61dfb0e6433b401)