| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
There was a problem hiding this comment.
exports.active() is defined at the top of the file
Sorry, something went wrong.
There was a problem hiding this comment.
Whoops, fixed.
Sorry, something went wrong.
|
pretty sure I thought this was a bad idea for some reason Edit: ¯\_(ツ)_/¯ |
Sorry, something went wrong.
There was a problem hiding this comment.
needs to test all 6 global timers functions
Sorry, something went wrong.
There was a problem hiding this comment.
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.
Sorry, something went wrong.
There was a problem hiding this comment.
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...?
Sorry, something went wrong.
There was a problem hiding this comment.
(Not much use in testing active though. Overwriting exported methods on core modules is no way guaranteed to be be safe.)
Sorry, something went wrong.
There was a problem hiding this comment.
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.
Sorry, something went wrong.
There was a problem hiding this comment.
@Fishrock123 I've updated the test to something that is what you describe, as I understand it. PTAL
Sorry, something went wrong.
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.
There was a problem hiding this comment.
is this possible? IIRC from before, you couldn't actually manually load internal modules from user code like tests.
Sorry, something went wrong.
There was a problem hiding this comment.
Already appears in five other tests!
Sorry, something went wrong.
There was a problem hiding this comment.
(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.)
Sorry, something went wrong.
Sorry, something went wrong.
|
Single failure in CI is an unrelated known flaky test. |
Sorry, something went wrong.
|
Would definitely prefer to have this sit in at least one v5 release for a week or two before backporting to v4 |
Sorry, something went wrong.
| delete global.setInterval; | ||
| delete global.clearInterval; | ||
| delete global.setImmediate; | ||
| delete global.clearImmediate; |
There was a problem hiding this comment.
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.
Sorry, something went wrong.
There was a problem hiding this comment.
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.)
Sorry, something went wrong.
|
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 |
Sorry, something went wrong.
|
@Fishrock123 Would you prefer this land as-is or would you prefer I back out the changes to active()? I think the change to active() makes sense, but if you have any doubts or concerns, I'm happy to back it out and anyone that feels strongly about it can put it in a separate PR. On the other hand, if it's OK by you, then I will land as-is. |
Sorry, something went wrong.
|
@Trott I think it is best to not make any guarantees in that area unless we do it globally, LGTM either way. |
Sorry, something went wrong.
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 <jasnell@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com> Fixes: nodejs#2493
PR-URL: nodejs#5882 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Sorry, something went wrong.
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 <jasnell@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com> Fixes: #2493
PR-URL: #5882 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
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 <jasnell@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com> Fixes: #2493
PR-URL: #5882 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
|
@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). |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Pull Request check-list
this 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