-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
async_hooks: fix Promises with later enabled hooks #13242
Conversation
src/async-wrap.cc
Outdated
if (type != PromiseHookType::kInit) { | ||
// Do not emit an init event. | ||
stored_init_field = env->async_hooks()->fields()[AsyncHooks::kInit]; | ||
env->async_hooks()->fields()[AsyncHooks::kInit] = 0; |
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.
well, this is a fun hack :) – I'm not sure I approve, would a default parameter in AsyncWrap::AsyncWrap
and AsyncWrap::AsyncReset
be that difficult?
@Fishrock123 thoughts?
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.
would a default parameter in
AsyncWrap::AsyncWrap
andAsyncWrap::AsyncReset
be that difficult?
@AndreasMadsen yeah no you’re right. done. 😄
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.
Although, I do think we should use
uint32_t* fields_ptr = async_hooks->fields();
if (fields_ptr[AsyncHooks::kInit] +
fields_ptr[AsyncHooks::kBefore] +
fields_ptr[AsyncHooks::kAfter] +
fields_ptr[AsyncHooks::kDestroy] > 0) {
}
instead of #13177 for a more consistent performance, when createHook()
has been called but no hooks are enabled. But that is not relevant in this PR.
@AndreasMadsen Yes, I see no problem with doing that too; but I would really like to keep the |
Makes sense. edit: the goal is that there is no difference between calling |
This looks good on my end. Sorry for the lack of bandwidth to address this on #13224 directly. |
@matthewloring No problem! This PR is me cleaning up my own mistake. If you want you can still cherry-pick 0ec3eba0534f7de36c6c2e8baa38188a5279727f into your PR so that it can land a bit earlier. |
As long as it gets in to node 8 I'm happy either way :) |
It shouldn’t be so terribly hard either. Maybe I can take a look after the current bunch of async_wrap PRs are through.
@matthewloring Yeah, me too. Maybe we should ask @nodejs/collaborators whether they think it’s a good idea to fast-track this? At this point you and @AndreasMadsen seem to be “the” most relevant reviewers for async_hooks by far… (speaking of which, would you mind giving #13142 a look? 😬) |
Promises do not have any internal fields by default. V8 recently added the capability of configuring the number of internal fields on promises. This change adds an internal field to promises allowing promises to be wrapped directly by the PromiseWrap object. In addition to cleaner code this avoids an extra object allocation per promise and speeds up promise creation with async_hooks enabled by ~2x.
Assign a `PromiseWrap` instance to Promises that do not have one yet when the PromiseHook is being called. Fixes: nodejs#13237
723198e
to
8adc1bb
Compare
8adc1bb
to
0f4e9da
Compare
Based on #13224
Fixes: #13237
/cc @AndreasMadsen @matthewloring @Fishrock123 @nodejs/diagnostics
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
async_hooks