-
Notifications
You must be signed in to change notification settings - Fork 29.7k
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
src: return early if nextTickQueue is empty #10274
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,32 @@ | ||
'use strict'; | ||
|
||
const common = require('../common'); | ||
const assert = require('assert'); | ||
var allsGood = false; | ||
var cntr = 0; | ||
|
||
process.on('exit', () => { | ||
assert.ok(cntr > 0, '_tickDomainCallback was never called'); | ||
}); | ||
|
||
/** | ||
* This test relies upon the following internals to work as specified: | ||
* - require('domain') causes node::Environment::set_tick_callback_function() | ||
* to use process._tickDomainCallback() to process the nextTickQueue; | ||
* replacing process._tickCallback(). | ||
* - setImmediate() uses node::MakeCallback() instead of | ||
* node::AsyncWrap::MakeCallback(). Otherwise the test will always pass. | ||
* Have not found a way to verify that node::MakeCallback() is used. | ||
*/ | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Could these conditions be checked by adding a test for the reverse situation? I.e. making sure that if there are ticks pending, the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This seems like a good idea. @trevnorris? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @Fishrock123 In response to my suggestion @trevnorris added the second (nested) |
||
process._tickDomainCallback = function _tickDomainCallback() { | ||
assert.ok(allsGood, '_tickDomainCallback should not have been called'); | ||
cntr++; | ||
}; | ||
|
||
setImmediate(common.mustCall(() => { | ||
require('domain'); | ||
setImmediate(common.mustCall(() => setImmediate(common.mustCall(() => { | ||
allsGood = true; | ||
process.nextTick(() => {}); | ||
})))); | ||
})); |
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.
If you think being stricter is okay, we could just wrap the fake
_tickDomainCallback
incommon.mustCall(·, 2)
(You can probably judge whether the number of calls is likely to change).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.
@addaleax Though on my machine it would be
common.mustCall(., 3)
. Because we can't actually process thenextTickQueue
when overriding_tickDomainCallback()
we can only guarantee it will be called at least once. I don't feel that being any stricter than that is possible w/o making some shaky assumptions on how the internals work.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.
Likewise, adding
mustCall()
toprocess.on('exit'
is pointless sincemustCall
callbacks are checked during'exit'
.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.
I think that settles it, thanks for checking!