Uh oh!
There was an error while loading. Please reload this page.
zlib: remove _closed - #6574
Conversation
This is purely cleanup and carries no visible behavioural changes. Up to now, `this._closed` was used in zlib.js as a synonym of `!this._handle`. This change makes this connection explicit and removes the `_closed` property from zlib streams, as the previous duplication has been the cause of subtle errors like nodejs#6034. This also makes zlib errors lead to an explicit `_close()` call rather than waiting for garbage collection to clean up the handle, thus returning memory resources earlier in the case of an error.
cjihrig
commented
May 4, 2016
Even though this was an underscored property, it should probably still go through a deprecation cycle. |
Trott
commented
May 4, 2016
You can de-semver-major-ize this PR by keeping A separate PR can remove it (or print a deprecation warning if it's accessed, or whatever the correct first deprecation step is in this situation). |
addaleax
commented
May 4, 2016
Eh, yes, I’m adding a getter for |
Add a getter for `_closed` so that the property remains accessible by legacy code.
addaleax
commented
May 4, 2016
Done. The OS X CI failure looks very unrelated, but I don’t recall it being mentioned as flaky anywhere, if anyone’s curious. |
Trott
commented
May 4, 2016
OS X thing sure looks unrelated. Maybe run a second CI just to make sure? Stranger things have happened, although not often. :-) |
addaleax
commented
May 4, 2016
cjihrig
commented
May 4, 2016
LGTM if the CI is happy. |
jasnell
commented
May 6, 2016
LGTM but if you happen to know of any modules that use zlib we may want to get those into citgm to make sure these kinds of changes don't have unintended drawbacks /cc @thealphanerd |
addaleax
commented
May 8, 2016
Hmm… there are each with > 500k npm downloads/month, I think that’s something? |
jasnell
commented
May 8, 2016
Works for me! |
addaleax
commented
May 11, 2016
I think this can be landed without an extra citgm run, but ping @thealphanerd … interested in adding the modules from above to the list? |
MylesBorins
commented
May 11, 2016
via email
I have a branch with the modules added to the lookup. I'll get a citgm run
later tonight or tomorrow |
addaleax
commented
May 11, 2016
Oh, okay then, sorry for bothering. ;-) |
MylesBorins
commented
May 11, 2016
via email
Not bothering at all. Totally spaced on following up in this thread 😊 |
addaleax
commented
May 17, 2016
Landed in b53473f |
This is purely cleanup and carries no visible behavioural changes. Up to now, `this._closed` was used in zlib.js as a synonym of `!this._handle`. This change makes this connection explicit and removes the `_closed` property from zlib streams, as the previous duplication has been the cause of subtle errors like #6034. This also makes zlib errors lead to an explicit `_close()` call rather than waiting for garbage collection to clean up the handle, thus returning memory resources earlier in the case of an error. Add a getter for `_closed` so that the property remains accessible by legacy code. PR-URL: #6574 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
This is purely cleanup and carries no visible behavioural changes. Up to now, `this._closed` was used in zlib.js as a synonym of `!this._handle`. This change makes this connection explicit and removes the `_closed` property from zlib streams, as the previous duplication has been the cause of subtle errors like #6034. This also makes zlib errors lead to an explicit `_close()` call rather than waiting for garbage collection to clean up the handle, thus returning memory resources earlier in the case of an error. Add a getter for `_closed` so that the property remains accessible by legacy code. PR-URL: #6574 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
MylesBorins
commented
Jun 2, 2016
@addaleax lts? |
This is purely cleanup and carries no visible behavioural changes. Up to now, `this._closed` was used in zlib.js as a synonym of `!this._handle`. This change makes this connection explicit and removes the `_closed` property from zlib streams, as the previous duplication has been the cause of subtle errors like #6034. This also makes zlib errors lead to an explicit `_close()` call rather than waiting for garbage collection to clean up the handle, thus returning memory resources earlier in the case of an error. Add a getter for `_closed` so that the property remains accessible by legacy code. PR-URL: #6574 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Checklist
Affected core subsystem(s)
zlib
Description of change
This is purely cleanup and carries no visible behavioural changes.
Up to now,
this._closedwas used in zlib.js as a synonym of!this._handle. This change makes this connection explicit and removes the_closedproperty from zlib streams, as the previous duplication has been the cause of subtle errors like #6034.This also makes zlib errors lead to an explicit
_close()call rather than waiting for garbage collection to clean up the handle, thus returning memory resources earlier in the case of an error.CI: https://ci.nodejs.org/job/node-test-commit/3184/