| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
This fixes an edge case where running this.unref() during the callback caused the callback to get executed multiple times.
There was a problem hiding this comment.
I think it's probably best to just do this before if (this._handle) {, but I'm not 100% sure it matters.
Sorry, something went wrong.
There was a problem hiding this comment.
Yes, I was unsure here too, but since I only wanted to prevent the _onTimeout call, this seemed right.
Sorry, something went wrong.
|
Was also trying fixes for this. I assumed this should also affect intervals, but it doesn't seem to.. |
Sorry, something went wrong.
|
Yeah, didn't see it on intervals either. Right now, I fail to even find where .start() is defined. |
Sorry, something went wrong.
Sorry, something went wrong.
|
Also, I think it needs a timer._called = false; here for intervals. Did the tests pass on the current patch? |
Sorry, something went wrong.
|
Yeah, tests did pass. Will research later. |
Sorry, something went wrong.
There was a problem hiding this comment.
Please add this._called = false to the constructor.
Sorry, something went wrong.
|
Overall I think this is a decent fix for the apparent issue at hand. Timers should be revisited in more detail later to cleanup the implementation. Minus one comment, LGTM. |
Sorry, something went wrong.
|
Thanks for the review, I'll update with your suggestion once I'm sure this doesn't affect setInterval. I might also revise some of the timer tests in process. I agree timers should be cleaned up or be rewritten at some point. It's very hard to follow the code flow, and there's probably a few perf gains to be had too. |
Sorry, something went wrong.
|
This is might be more related to #1152 / #1151 than initially thought. Failing test: var assert = require('assert');
setImmediate(function () {
var count = 0;
while (count++ < 1e7) {
Math.random()
}
});
var i = setTimeout(function () {
this.unref();
setImmediate(process.exit);
}, 10);
process.on('exit', function() {
assert.strictEqual(process._getActiveHandles().length, 0);
});Edit: updated test asset |
Sorry, something went wrong.
|
That test still fails with my current patch. |
Sorry, something went wrong.
|
@silverwind hmm, don't let it hold this patch up though. It may or may not be related. |
Sorry, something went wrong.
|
Ah, wait, I derped the build appararently, retesting. edit: nope, linked test still failing with a clean build, so probably unrelated. |
Sorry, something went wrong.
|
@Fishrock123 turns out unref() during the setInterval callback did fail with my patch (it kept the process running), the last test is for that case. |
Sorry, something went wrong.
|
Alright, I'm pretty confident that this should solve the setInterval issue (I identify a interval by the ._repeat prop), and it shouldn't cause new leaks by letting the unenroll call go through. The added setInterval test doesn't assert anything and is only there to possibly timeout that test. PTAL @Fishrock123 @trevnorris |
Sorry, something went wrong.
|
Doesn't fix everything, but does it does fix known bugs. LGTM. |
Sorry, something went wrong.
|
LGTM please land |
Sorry, something went wrong.
|
Here's a CI for good measure though: https://jenkins-iojs.nodesource.com/view/iojs/job/iojs+any-pr+multi/374/ |
Sorry, something went wrong.
|
CI is happier than it looks. Those errors have been resolved since this pr's base. |
Sorry, something went wrong.
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: #1191 Reviewed-by: Trevor Norris <trev.norris@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com> PR_URL: #1231
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: #1191 Reviewed-by: Trevor Norris <trev.norris@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com> PR-URL: #1231
Notable changes: * fs: corruption can be caused by fs.writeFileSync() and append-mode fs.writeFile() and fs.writeFileSync() under certain circumstances, reported in #1058, fixed in #1063 (Olov Lassus). * iojs: an "internal modules" API has been introduced to allow core code to share JavaScript modules internally only without having to expose them as a public API, this feature is for core-only #848 (Vladimir Kurchatkin). * timers: two minor problems with timers have been fixed: - Timer#close() is now properly idempotent #1288 (Petka Antonov). - setTimeout() will only run the callback once now after an unref() during the callback #1231 (Roman Reiss). * Windows: a "delay-load hook" has been added for compiled add-ons on Windows that should alleviate some of the problems that Windows users may be experiencing with add-ons in io.js #1251 (Bert Belder). * V8: minor bug-fix upgrade for V8 to 4.1.0.27. * npm: upgrade npm to 2.7.4. See npm CHANGELOG.md for details.
| Back | FazBrowse Home | New Git URL |
This fixes #1191 by adding a property to track if the callback was run, and if so, prevents it from running again during a .unref().
I woul've loved to do it without the property, but couldn't find any way to find out whether the callback already ran.
r=@bnoordhuis @trevnorris