-
Notifications
You must be signed in to change notification settings - Fork 29.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ensure async iteration works with destroyed streams #23785
Conversation
@mcollina does this supersede my zlib destroy leak PR? |
@mafintosh which one? Very likely that should be merged first. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems this relies on a race condition? I won't pretend to know anything about our crazy streams but I want to just verify what's going on here is what is intended.
if (this[kStream].destroyed) { | ||
// this is needed because if .destro(err) is called, the error | ||
// will be emitted via nextTick | ||
return new Promise((resolve, rejects) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
any reason for rejects
rather than reject
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
none, I’ll fix it.
@devsnek this is normalizing a race condition that we cannot get rid of inside our stream machinery :/. |
Ah I didn’t know we were working on essentially the same issue! Can you pick up the change that I did inside processCallback? It might even be worth a test on its own. I’ll rebase this on top of yours. |
lib/zlib.js
Outdated
|
||
Zlib.prototype._destroy = function(err, cb) { | ||
const handle = this._handle; | ||
if (handle && handle.buffer !== null) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add a comment here describing what this condition means?
lib/zlib.js
Outdated
_close(this, callback); | ||
this.destroy(); | ||
Zlib.prototype.close = function(callback) { | ||
this.destroy(null, callback); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This changes timing for the close callback… is that intentional?
CI: https://ci.nodejs.org/job/node-test-pull-request/18090/ PTAL, this should be ready for review. |
@@ -158,6 +174,9 @@ const createReadableStreamAsyncIterator = (stream) => { | |||
stream.on('readable', onReadable.bind(null, iterator)); | |||
stream.on('end', onEnd.bind(null, iterator)); | |||
stream.on('error', onError.bind(null, iterator)); | |||
// needed because some streams will not emit 'end', e.g. Zlib. | |||
// https://github.com/nodejs/node/issues/23730 | |||
stream.on('close', onEnd.bind(null, iterator)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could use stream.finished to simplify in the future, but 👍
const passthrough = new PassThrough(); | ||
const err = new Error('kaboom'); | ||
pipeline(readable, passthrough, common.mustCall((e) => { | ||
assert.strictEqual(err, e); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
assert.strictEqual(err, e); | |
assert.strictEqual(e, err); |
try { | ||
await readable[Symbol.asyncIterator]().next(); | ||
} catch (e) { | ||
assert.strictEqual(err, e); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
assert.strictEqual(err, e); | |
assert.strictEqual(e, err); |
@mcollina There’s nothing speaking against landing this as far as I am concerned :) |
CI: https://ci.nodejs.org/job/node-test-pull-request/18110/ PTAL, I've switched to use |
Still LGTM. |
Landed in 3ec8cec |
(Also still LGTM for the record) |
Landed in 10.x with 398418d and b1e1fe4 Please lmk if it should be backed out |
go for it!
Il giorno lun 26 nov 2018 alle 22:41 Myles Borins <notifications@github.com>
ha scritto:
… Landed in 10.x with 398418d
<398418d>
and b1e1fe4
<b1e1fe4>
Please lmk if it should be backed out
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#23785 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AADL4-2fOTTylhaBVvajyK70fXegKpuvks5uzGAUgaJpZM4Xx6oH>
.
|
This PR is twofold:
makes sure thatdone in zlib: do not leak on destroy #23734.destroy()
works correctly on zlib streams (before it was not cleaning up the_handle
)Fixes #23730 .
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes