-
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
async_hooks: implement C++ embedder API #13142
Conversation
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’ve got a few questions about edge cases where it would be cool if @AndreasMadsen or @trevnorris could chime in.
Also, I can open a separate PR for cfe5d401921e72af3f6dc03a5a373401ba4e32e8 because it’s not really related to the rest here, and could be backported to all release lines if you think that makes sense.
src/node.cc
Outdated
env->immediate_callback_string(), | ||
0, | ||
nullptr, | ||
0).ToLocalChecked(); |
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.
There should be no async hooks firing for the call that runs setImmediate()
timers, 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.
sigh, I think this is correct. /cc @Fishrock123
src/node.cc
Outdated
MakeCallback(env, process_object, "emit", arraysize(args), args); | ||
MakeCallback(env->isolate(), | ||
process_object, "emit", arraysize(args), args, | ||
0).ToLocalChecked(); |
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’m really not sure whether 0
is correct here.
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.
Good question. In theory, we should only have 0
as the id when the resource is unknown, which should only happen because of legacy code.
I'm not really sure what the appropriate resource is, I guess we could create an event-loop resource on startup.
src/node_crypto.cc
Outdated
sc->object(), | ||
env->ticketkeycallback_string(), | ||
arraysize(argv), | ||
argv); | ||
argv, | ||
0).ToLocalChecked(); |
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.
ditto
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 SecureContext
inherits from AsyncWrap
as @trevnorris suggests this problem should be solved.
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.
See #13176, I don’t think we need to actually care about this
src/node_crypto.cc
Outdated
Local<Value> ret = node::MakeCallback(env, | ||
|
||
// TODO(addaleax): `SecureContext` should maybe inherit from AsyncWrap? | ||
Local<Value> ret = node::MakeCallback(env->isolate(), |
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.
Hm. I missed this. This should inherit from AsyncWrap
.
src/node.h
Outdated
async_uid asyncId, | ||
async_uid triggerId = -1); | ||
|
||
/* Helper class users can inherit from, but is not necessary. If |
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.
Suggestion: Helper class users can optionally inherit from.
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.
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.
Thanks for taking the time to implement this, here is my initial review:
-
Can we not use
DomainEnter
andDomainExit
inMakeCallback
? -
How is the trigger set in the
Init
emit?set_init_trigger_id
is not a public API, I think we need to maketrigger_id
an option inEmitAsyncInit
andAsyncResource::AsyncResource
. That should also allow us to removetrigger_id
fromAsyncResource::MakeCallback
.
/* Helper class users can optionally inherit from. If | ||
* `AsyncResource::MakeCallback()` is used, then all four callbacks will be | ||
* called automatically. */ | ||
class AsyncResource { |
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.
In the JS Embedder API this is called AsyncEvent
, I actually like the AsyncResource
name better, but at the very least it is inconsistent.
Can you be a bit more specific why we wouldn’t want to use these?
|
Sorry, I think I messed up in language negatives. I meant:
|
e6c71b6
to
de2fba0
Compare
done
done! |
src/node.h
Outdated
async_uid trigger_id = -1) { | ||
return node::MakeCallback(isolate_, get_resource(), | ||
callback, argc, argv, | ||
uid_, trigger_id); |
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.
The trigger_id
passed to AsyncResource::MakeCallback
should be the same as the one passed to AsyncResource::AsyncResource
, so I think we should just store trigger_id
in a private field in AsyncResource::AsyncResource
and use that field in AsyncResource::MakeCallback
.
That way we don't need the trigger_id
argument in AsyncResource::MakeCallback
.
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.
Done, although I have to admit I’m not a hundred percent sure what the semantics of trigger_id
in before/after hooks would be if the value is always the same that was passed for the init hook … maybe I share @joshgav’s confusion about it? ;)
48a3c4f
to
616a20f
Compare
This is based on top of the current version of #13000, and currently still missing tests./cc @nodejs/diagnostics and in particular @AndreasMadsen @trevnorris @matthewloring @danbev
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
async_hooks