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

10588 Commits

131 Branches

446 Tags

325 MiB

Tree: b1a208c83c

Commit Graph

Author	SHA1	Message	Date
Fedor Indutny	0e19476595	test: split test in parallel/sequential Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> PR-URL: https://github.com/iojs/io.js/pull/172 Fix: iojs/io.js#139	10 years ago
isaacs	327b6e3e1d	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	12 years ago

Author

SHA1

Message

Date

Fedor Indutny

0e19476595

test: split test in parallel/sequential

Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
PR-URL: https://github.com/iojs/io.js/pull/172
Fix: iojs/io.js#139

10 years ago

isaacs

327b6e3e1d

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

12 years ago

1 Commits (b1a208c83cdea0a259cc557314a9566dcad9b5b2)