-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
timers: fixing API refs to use safe internal refs #5882
Conversation
var msecs = item._idleTimeout; | ||
if (msecs >= 0) | ||
insert(item, msecs); | ||
}; |
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.
exports.active()
is defined at the top of the file
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.
Whoops, fixed.
pretty sure I thought this was a bad idea for some reason Edit: |
|
||
// try overriding global APIs to make sure | ||
// they're not relied on by the timers | ||
global.clearTimeout = assert.fail; |
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.
needs to test all 6 global timers functions
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.
You can't access 3 of the six. They're on the public API of the module, but that's not available to user code like tests.
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.
I don't think I understand?
if any of:
setTimeout()
clearTimeout()
setInterval()
clearInterval()
setImmediate()
clearImmediate()
Are using the exported or global version for specific internal-only behavior and then someone overwrites them, there will be problems...?
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.
(Not much use in testing active
though. Overwriting exported methods on core modules is no way guaranteed to be be safe.)
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.
sorry i was recalling that we couldn't test the active and enroll methods, etc. I also didn't know the *immediate stuff was in here. perhaps that was put in this file sometime after my initial PR when I looked at this code last.
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.
@Fishrock123 I've updated the test to something that is what you describe, as I understand it. PTAL
Added safe internal references for 'clearTimeout(..)', 'active(..)', and 'unenroll(..)'. Changed various API refs from 'export.*' to use these safe internal references. Now, overwriting the global API identifiers does not create potential breakage and/or race conditions. See Issue nodejs#2493.
1cdaeae
to
ad31a52
Compare
@@ -1,20 +1,24 @@ | |||
'use strict'; | |||
const common = require('../common'); | |||
const assert = require('assert'); | |||
const timers = require('timers'); |
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.
is this possible? IIRC from before, you couldn't actually manually load internal modules from user code like tests.
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.
Already appears in five other tests!
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.
(Also: Yeah, it works. Test fails with a ReferenceError
in Node 5.9.1, as it should, and passes with your changes in lib/timers.js
.)
ad31a52
to
e1f5bb8
Compare
Single failure in CI is an unrelated known flaky test. |
LGTM if @Fishrock123 is happy. |
Would definitely prefer to have this sit in at least one v5 release for a week or two before backporting to v4 |
delete global.setInterval; | ||
delete global.clearInterval; | ||
delete global.setImmediate; | ||
delete global.clearImmediate; |
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.
You've also changed active
, but I'm not comfortable enforcing that in the tests. We should have a policy if module exports are always overridable.
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.
I agree that if you override timers.active()
, then you're on your own and have to manage any possible side effects yourself. (That said, I do think it's worthwhile for timers.js
to guard against the problem internally, as it does in this PR, as long as there's no reason to suspect a performance hit or other unanticipated side effect.)
LGTM for the globals. This can land on 4.x with little issue imo. (Might need to resolve conflicts if you haven't landed my timers refactor, but it should be an easy resolution.) The code poses zero realistic risk if the CI passes |
@Fishrock123 Would you prefer this land as-is or would you prefer I back out the changes to I think the change to On the other hand, if it's OK by you, then I will land as-is. |
@Trott I think it is best to not make any guarantees in that area unless we do it globally, LGTM either way. |
Added safe internal references for 'clearTimeout(..)', 'active(..)', and 'unenroll(..)'. Changed various API refs from 'export.*' to use these safe internal references. Now, overwriting the global API identifiers does not create potential breakage and/or race conditions. See Issue nodejs#2493. PR-URL: nodejs#5882 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Jeremiah Senkpiel <[email protected]> Fixes: nodejs#2493
PR-URL: nodejs#5882 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Jeremiah Senkpiel <[email protected]>
Added safe internal references for 'clearTimeout(..)', 'active(..)', and 'unenroll(..)'. Changed various API refs from 'export.*' to use these safe internal references. Now, overwriting the global API identifiers does not create potential breakage and/or race conditions. See Issue #2493. PR-URL: #5882 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Jeremiah Senkpiel <[email protected]> Fixes: #2493
PR-URL: #5882 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Jeremiah Senkpiel <[email protected]>
Added safe internal references for 'clearTimeout(..)', 'active(..)', and 'unenroll(..)'. Changed various API refs from 'export.*' to use these safe internal references. Now, overwriting the global API identifiers does not create potential breakage and/or race conditions. See Issue #2493. PR-URL: #5882 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Jeremiah Senkpiel <[email protected]> Fixes: #2493
PR-URL: #5882 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Jeremiah Senkpiel <[email protected]>
@Fishrock123 this relies on your other timer changes correct? I think the idea was to let those changes live in v5 a little longer to catch edges (such as this one). |
Which changes? This should land cleanly onto v5.x I think, but it does still apply (not in the git sense) to v4.x even without the other patches. |
Pull Request check-list
make -j8 test
(UNIX) orvcbuild test nosign
(Windows) pass withthis change (including linting)?
test (or a benchmark) included?
existing APIs, or introduces new ones)?
Affected core subsystem(s)
timers
Description of change
Added safe internal references for 'clearTimeout(..)', 'active(..)', and
'unenroll(..)'. Changed various API refs from 'export.*' to use these
safe internal references.
Now, overwriting the global API identifiers does not create potential
breakage and/or race conditions. See Issue #2493.
Refs: #2493
Refs: #2500
/cc @getify @Fishrock123 @targos