Repository navigation
setTimeout can fire twice #1191
Description
Activity
- addedtimersIssues and PRs related to timers, setImmediate(), setInterval(), and setTimeout().Issues and PRs related to timers, setImmediate(), setInterval(), and setTimeout().
on Mar 18, 2015 For posterity this was found during irc discussion with @trevnorris last night regarding #1152 -- http://logs.libuv.org/io.js/2015-03-17#23:26:55.816
- addedconfirmed-bugIssues and PRs for confirmed bugs.Issues and PRs for confirmed bugs.
on Mar 18, 2015 Looks a
unref()is enough to trigger it:$ NODE_DEBUG=timer iojs -e "setTimeout(function() { console.log('hi'); this.unref(); }, 10)" TIMER 46607: timeout callback 1 TIMER 46607: now: 17345754 hi TIMER 46607: unenroll TIMER 46607: unenroll: list empty TIMER 46607: 1 list empty hiWhy does
Timeout.prototype.unrefrun the timer again (throughthis._handle.start(delay, 0);, I assume) ?Or rather, I think the issue is with the unenroll list being empty.
It seems to me as though it doesn't expect you to unref during it's own callback. I.e. it does not check that the callback has already been or is being called..
I'm pretty certain that
unenrollisn't working as expected in this case. The timer code is pretty convoluted I have to say.I'm not sure unref needs to make a handle in the case that the callback is already being called.
Yeah, it's too late to unref a already fired timer, that
unref()should be noop. The problem now is how do we know theTimeout._onTimeoutfired? add something likedTimeout._fired = trueand check thatTimeout.prototype.unref? Any other suggestions?Hold on, I got an idea.
Nope, I think I can't do without a tracking property on the timeout. 😢
- added a commit that references this issue
on Mar 26, 2015 Fixed in b0f8e30
- added a commit that references this issue
on Mar 26, 2015
Test to reproduce:
I haven't had the time to investigate, but want to make sure this issue can be tracked.