Skip to content
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

Closed
wants to merge 2 commits into from

Conversation

Trott
Copy link
Member

@Trott Trott commented Mar 23, 2016

Pull Request check-list

  • Does make -j8 test (UNIX) or vcbuild test nosign (Windows) pass with
    this change (including linting)?
  • Is the commit message formatted according to [CONTRIBUTING.md][0]?
  • If this change fixes a bug (or a performance problem), is a regression
    test (or a benchmark) included?
  • Is a documentation update included (if this change modifies
    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

@Trott Trott added timers Issues and PRs related to the timers subsystem / setImmediate, setInterval, setTimeout. lts-watch-v4.x labels Mar 23, 2016
var msecs = item._idleTimeout;
if (msecs >= 0)
insert(item, msecs);
};
Copy link
Contributor

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whoops, fixed.

@Fishrock123
Copy link
Contributor

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;
Copy link
Contributor

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

Copy link
Contributor

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.

Copy link
Contributor

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...?

Copy link
Contributor

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.)

Copy link
Contributor

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.

Copy link
Member Author

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.
@Trott Trott force-pushed the fix-timers-api-refs branch 3 times, most recently from 1cdaeae to ad31a52 Compare March 24, 2016 22:18
@@ -1,20 +1,24 @@
'use strict';
const common = require('../common');
const assert = require('assert');
const timers = require('timers');
Copy link
Contributor

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.

Copy link
Member Author

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!

Copy link
Member Author

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.)

@Trott
Copy link
Member Author

Trott commented Mar 25, 2016

@Trott
Copy link
Member Author

Trott commented Mar 25, 2016

Single failure in CI is an unrelated known flaky test.

@jasnell
Copy link
Member

jasnell commented Mar 26, 2016

LGTM if @Fishrock123 is happy.

@jasnell
Copy link
Member

jasnell commented Mar 26, 2016

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;
Copy link
Contributor

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.

Copy link
Member Author

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.)

@Fishrock123
Copy link
Contributor

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

@Trott
Copy link
Member Author

Trott commented Mar 28, 2016

@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.

@Fishrock123
Copy link
Contributor

@Trott I think it is best to not make any guarantees in that area unless we do it globally, LGTM either way.

Trott pushed a commit to Trott/io.js that referenced this pull request Mar 28, 2016
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
Trott added a commit to Trott/io.js that referenced this pull request Mar 28, 2016
PR-URL: nodejs#5882
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Jeremiah Senkpiel <[email protected]>
@Trott
Copy link
Member Author

Trott commented Mar 28, 2016

Landed in 9fa25c8 and f0367d0

@Trott Trott closed this Mar 28, 2016
evanlucas pushed a commit that referenced this pull request Mar 30, 2016
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
evanlucas pushed a commit that referenced this pull request Mar 30, 2016
PR-URL: #5882
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Jeremiah Senkpiel <[email protected]>
evanlucas pushed a commit that referenced this pull request Mar 31, 2016
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
evanlucas pushed a commit that referenced this pull request Mar 31, 2016
PR-URL: #5882
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Jeremiah Senkpiel <[email protected]>
@MylesBorins
Copy link
Contributor

@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).

@Fishrock123
Copy link
Contributor

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.

@Trott Trott deleted the fix-timers-api-refs branch January 13, 2022 22:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
timers Issues and PRs related to the timers subsystem / setImmediate, setInterval, setTimeout.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants