-
Notifications
You must be signed in to change notification settings - Fork 30.2k
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
timer: make sure timer is cleared #4303
Conversation
Can you add tests? |
Ok, I will add test. And before that, i should fix another test. :-). |
tests added, @mscdex THANKS |
I think it'd be better to forgo the use of child processes and just execute the timer tests directly. Also, instead of using counters, you might use |
But mustCall can't check how many times an internal function executed. This fix is to make sure listOnTimeout(the same as exports.active) should not be triggered again after close/unenroll in setInterval callback. |
lib/timers.js
Outdated
@@ -264,7 +264,7 @@ exports.setInterval = function(callback, repeat) { | |||
timer._repeat.call(this); | |||
|
|||
// Timer might be closed - no point in restarting it | |||
if (!timer._repeat) | |||
if ((!timer._repeat) || ((timer._idleTimeout === -1) && (!this._handle))) |
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.
Nit: there's an extra set or parenthesis here.
Also I think the check should prioritize timer._idleTimeout === -1
, and only check ._repeat
for legacy purposes.
I'm not entirely sure checking the handle is necessary. (Aside: Timer#unref()
should probably check ._idleTimeout === -1
, I think.)
Maybe the legacy logic to prioritize to check timer._repeat is result of calling clearTimeout/clearInterval more often than close/unenroll. Check handle is necessary for unref() timer. (test case: test/parallel/test-timers-unrefd-interval-still-fires.js) |
@zhangzifa Right, neither Checking |
@Fishrock123 I agree with you that check Someone optimized |
@zhangzifa That search has a lot of false positives, GitHub search is not very good for that.
Pardon? https://github.com/nodejs/node/blob/master/lib/timers.js#L122-L139 |
@Fishrock123 Sorry, my local copy is out of date. My copy is before this PR.#3407 |
lib/timers.js
Outdated
@@ -276,7 +276,7 @@ exports.setInterval = function(callback, repeat) { | |||
timer._repeat(); | |||
|
|||
// Timer might be closed - no point in restarting it | |||
if (!timer._repeat) | |||
if ((!timer._repeat) || ((timer._idleTimeout === -1) && (!this._handle))) |
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.
There's two extra sets or parenthesis here.
Also, could you make the change to prioritize timer._idleTimeout === -1
? Thanks!
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.
Checking timer._idleTimeout === -1
is enough, if _idleTimeout
should be set to -1
in Timeout.prototype.close
when this._handle
is true.
|
Yes, the old implementation missed to assign |
One of the filenames has a typo in it: |
nbIntervalFired3++; | ||
T.unenroll(timer3); | ||
}, 13); | ||
setTimeout(() => { |
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 we can't just do this?:
- Move this file to
/test/parallel
- Add
const common = require('../common');
to the top. - Surround the arrow function here with
common.mustCall()
Get rid oftest-timers-disarmed-in-callbak-not-fire-anymore.js
Never mind!
listOnTimeout will be called again which should not be called anymore. When unenroll is called in timer(set by setInterval) callback, the timer still works. With this fix, the timer behaves the same as clearTimeout/clearInterval is called in callback.
Hey @zhangzifa, I believe this would be your first commit to core if it gets in, welcome to the project! As I think you're finding out here, messing around with timers code can be tricky and involve a lot of edge-cases that are not necessarily covered by tests. Expect this PR to continue to be picked over by other collaborators before anything's ready to be merged. It's also possible that this might go another way, such as just deprecating |
@rvagg Happy new year! Yes, it's my first PR to this project. I'm puzzled why |
I wonder somewhat how useful the I figure we should probably patch this anyways, deprecating the latter, at least, would be quite an extended process I think. |
Note that, before ~March 2015, we did not have |
Hi @Fishrock123. Incredibly someone is using |
Interesting. Perhaps we should still look at |
It seems not easy to find in which module |
What's the status on this one? |
7da4fd4
to
c7066fb
Compare
CI against current master: https://ci.nodejs.org/job/node-test-pull-request/4260/ |
c133999
to
83c7a88
Compare
@Fishrock123 ... any thoughts on this one? |
The tests appear to pass on |
The tests here should also not be necessary, I think. |
@zhangzifa Thanks anyways for reporting this! Sorry it took so long. 😅 |
-- when close called in callback, an extra active is called.
-- when unenroll called, the timer is still working