-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
perf_hooks: fix scheduling regression #18051
perf_hooks: fix scheduling regression #18051
Conversation
cc @addaleax |
Scheduling a PerformanceGCCallback should not keep the loop alive but due to the recent switch to using the native SetImmediate method, it does. Go back to using uv_async_t and add a regression test.
469ae0f
to
c5cc04f
Compare
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.
LGTM
I kind of feel like this would better handled eventually by allowing SetImmediate()
s to be unrefed, but I guess that would require somebody to make that happen ;)
let didCall = false; | ||
process.on('beforeExit', () => { | ||
assert(!didCall); | ||
didCall = true; |
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.
You could just use common.mustCall()
on the beforeExit
handler instead of tracking via didCall
, right?
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.
Nope, that would create an infinite loop of always doing more GC and restarting beforeExit
.
@addaleax ... Yes, I agree that having the option of unref'ing the |
Failures on plinux
also linuxone
|
linux one rerun: https://ci.nodejs.org/job/node-test-commit-linuxone/11748/ |
I do not believe those are related to this. Also, there were two CIs earlier that were both fully successful. This didn't need a third run. |
plinux rerun: https://ci.nodejs.org/job/node-test-commit-plinux/14448/ |
CI is looking good, I'll be getting this landed. |
Scheduling a PerformanceGCCallback should not keep the loop alive but due to the recent switch to using the native SetImmediate method, it does. Go back to using uv_async_t and add a regression test. PR-URL: nodejs#18051 Fixes: nodejs#18047 Refs: nodejs#18020 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
Landed in ececdd3 |
Scheduling a PerformanceGCCallback should not keep the loop alive but due to the recent switch to using the native SetImmediate method, it does. Go back to using uv_async_t and add a regression test. PR-URL: nodejs#18051 Fixes: nodejs#18047 Refs: nodejs#18020 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
Scheduling a PerformanceGCCallback should not keep the loop alive but due to the recent switch to using the native SetImmediate method, it does. Go back to using uv_async_t and add a regression test. Backport-PR-URL: #18050 PR-URL: #18051 Fixes: #18047 Refs: #18020 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
Scheduling a PerformanceGCCallback should not keep the loop alive but due to the recent switch to using the native SetImmediate method, it does. Go back to using uv_async_t and add a regression test. Backport-PR-URL: #18050 PR-URL: #18051 Fixes: #18047 Refs: #18020 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
Scheduling a PerformanceGCCallback should not keep the loop alive but due to the recent switch to using the native SetImmediate method, it does. Go back to using uv_async_t and add a regression test. PR-URL: #18051 Fixes: #18047 Refs: #18020 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
Scheduling a PerformanceGCCallback should not keep the loop alive but due to the recent switch to using the native SetImmediate method, it does. Go back to using uv_async_t and add a regression test. PR-URL: #18051 Fixes: #18047 Refs: #18020 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
Scheduling a PerformanceGCCallback should not keep the loop alive but due to the recent switch to using the native SetImmediate method, it does. Go back to using uv_async_t and add a regression test. PR-URL: #18051 Fixes: #18047 Refs: #18020 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
Scheduling a
PerformanceGCCallback
should not keep the event loop alive but due to the recent switch to using the nativeSetImmediate
method, it does. Go back to usinguv_async_t
and add a regression test.The reason this was uncovered by the
http2
binding is that it takes just long enough to do the GC on all the string constants that it creates that this race condition was triggered. (I finally uncovered this when the problem went away simply by commenting outHTTP_KNOWN_HEADERS(STRING_CONSTANT)
innode::http2::Initialize
.)Refs: #18020
Fixes: #18047
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
perf_hooks, src