timers: cleanup interval handling

[Fishrock123]

Uses null as the false-y value for _repeat as like other properties.

Removes un-reachable statement in setInterval’s wrapper().

The path that clearing an interval takes is this:

• https://github.com/iojs/io.js/blob/v1.x/lib/timers.js#L291
• https://github.com/iojs/io.js/blob/v1.x/lib/timers.js#L225
• https://github.com/iojs/io.js/blob/v1.x/lib/timers.js#L333
  • https://github.com/iojs/io.js/blob/v1.x/lib/timers.js#L73
  • (or)
  • https://github.com/iojs/io.js/blob/v1.x/lib/timers.js#L494

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

[trevnorris]

LGTM

[bnoordhuis]

CI: https://jenkins-iojs.nodesource.com/view/iojs/job/iojs+any-pr+multi/377/

[Fishrock123]

New windows errors appear to be from something in v1.x: https://jenkins-iojs.nodesource.com/view/iojs/job/iojs+any-pr+multi/376/

[Fishrock123]

@bnoordhuis LGTY?

Edit: hmm, let me try this before some of those recent commits.

[Fishrock123]

CI for this change against the last known 'green' base: https://jenkins-iojs.nodesource.com/view/iojs/job/iojs+any-pr+multi/378/

[Fishrock123]

Hmmm. There is no way this change should effect this?

Edit: how in the hell is a timer firing 1.25ms early?

=== release test-timers-first-fire ===
Path: parallel/test-timers-first-fire
timer fired in -1.2554560000000023
assert.js:87
throw new assert.AssertionError({
^
AssertionError: Timer fired early
at null._onTimeout (c:\workspace\iojs+any-pr+multi\nodes\iojs-win2012r2\test\parallel\test-timers-first-fire.js:11:10)
at Timer.listOnTimeout (timers.js:88:15)
Command: c:\workspace\iojs+any-pr+multi\nodes\iojs-win2012r2\Release\iojs.exe c:\workspace\iojs+any-pr+multi\nodes\iojs-win2012r2\test\parallel\test-timers-first-fire.js

https://jenkins-iojs.nodesource.com/view/iojs/job/iojs+any-pr+multi/378/nodes=iojs-win2012r2/console

[Arnavion]

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.

[Fishrock123]

Thanks, landed in 776b73b (weird, it didn't see this as a merge.)

[trevnorris]

@Fishrock123 don't think you pushed this up to iojs.

[trevnorris]

Also that time is us, not ms, iirc.

[Fishrock123]

It's pushed to iojs, but I guess it didn't push to my PR branch properly. Oh well.

[silverwind]

The PR actually contains my previously amended commit, so that's probably the cause of confusion.

[Fishrock123]

Yeah, it's just github being silly.

[Fishrock123]

I mucked this up. Fedor is fixing it as part of #1330