timers: cleanup interval handling #1272
Conversation
Calling this.unref() during the callback of SetTimeout caused the callback to get executed twice because unref() didn't expect to be called during that time and did not stop the ref()ed Timeout but did start a new timer. This commit prevents the new timer creation when the callback was already called. Fixes: nodejs#1191 Reviewed-by: Trevor Norris <trev.norris@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com> PR_URL: nodejs#1231
|
LGTM |
Uses `null` as the false-y value for `_repeat` as like other properties. Removes un-reachable statement in setInterval’s `wrapper()`. PR-URL: nodejs#1272 Reviewed-by: Trevor Norris <trev.norris@gmail.com>
8baf1d3 to
bb2a99b
Compare
|
New windows errors appear to be from something in v1.x: https://jenkins-iojs.nodesource.com/view/iojs/job/iojs+any-pr+multi/376/ |
|
@bnoordhuis LGTY? Edit: hmm, let me try this before some of those recent commits. |
|
CI for this change against the last known 'green' base: https://jenkins-iojs.nodesource.com/view/iojs/job/iojs+any-pr+multi/378/ |
|
Hmmm. There is no way this change should effect this? Edit: how in the hell is a timer firing 1.25ms early? https://jenkins-iojs.nodesource.com/view/iojs/job/iojs+any-pr+multi/378/nodes=iojs-win2012r2/console |
|
uv__hrtime uses double arithmetic on the 64-bit int returned by QueryPerformanceCounter. hrtime_interval_ is a double calculated as 1.0 / QPFrequency. This double arithmetic is potentially the source of the inaccuracies. QPC should only be used for calculating deltas, and these deltas should be calculated on the int64 itself. The value can be very large - QPC is allowed to overflow after 100 years (2^32 seconds) which means that an interval of a single second can contribute to 33 significant digits in the result. |
Uses `null` as the false-y value for `_repeat` as like other properties. Removes un-reachable statement in setInterval’s `wrapper()`. PR-URL: nodejs#1272 Reviewed-by: Trevor Norris <trev.norris@gmail.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
|
Thanks, landed in 776b73b (weird, it didn't see this as a merge.) |
|
@Fishrock123 don't think you pushed this up to iojs. |
|
Also that time is us, not ms, iirc. |
|
It's pushed to iojs, but I guess it didn't push to my PR branch properly. Oh well. |
|
The PR actually contains my previously amended commit, so that's probably the cause of confusion. |
|
Yeah, it's just github being silly. |
Eliminates floating-point operations that can cause precision loss. Thanks to @Arnavion for suggesting the fix: nodejs/node#1272 (comment)
Eliminates floating-point operations that can cause precision loss. Thanks to @Arnavion for suggesting the fix: nodejs/node#1272 (comment)
There was a problem hiding this comment.
I mucked this up. Fedor is fixing it as part of #1330
Reduces floating-point operations that can cause precision loss. Thanks to @Arnavion for suggesting the fix: nodejs/node#1272 (comment)
Reduces floating-point operations that can cause precision loss. Thanks to @Arnavion for suggesting the fix: nodejs/node#1272 (comment)
Uses
nullas the false-y value for_repeatas like other properties.Removes un-reachable statement in setInterval’s
wrapper().The path that clearing an interval takes is this:
As such, it will never be called. If someone were to manually set it in the callback,
timer._repeat.call(this);would throw anyways.R=@trevnorris / @bnoordhuis / @silverwind