-
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
n-api: napi_make_callback emit async init event with resource of async_context #32930
Conversation
This duplicates a lot of code from |
Yes, this is for
Could you elaborate on how this would be breaking to existing N-API codes? It seems to me doesn't break codes and behaviors? (They are not working as expected already). |
cc @nodejs/n-api @nodejs/diagnostics The approach seems reasonable. Could use some more review from people that know n-api better though, especially around ABI impact. |
8ae28ff
to
2935f72
Compare
I think we discussed this in the last N-API team meeting and @legendecas just needs to find some time to get back to it. |
eb5fdef
to
242acad
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.
Overall LGTM, but might be good to do something with that unused resource or people might get confused if they try to use a different resource and it silently ignores it. 🤔
@@ -627,26 +692,19 @@ NAPI_NO_RETURN void napi_fatal_error(const char* location, | |||
} | |||
|
|||
napi_status napi_open_callback_scope(napi_env env, | |||
napi_value resource_object, | |||
napi_value /** ignored */, |
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.
Should we perhaps use the resource_object
to warn if it's different than the object contained in the AsyncContext
?
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.
@quad I see what you mean, but that might be a breaking change and we don't have breaking changes for N-API methods. If we felt strongly about it we should add a new method without the parameter and doc deprecate the existing method (but not remove of course). I think we did something similar for another API in terms of indicate /** ignored */
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 was just thinking a log message warning, no change in behaviour. Is that still considered breaking? Either way, not blocking on that. Just a thought that it'd be nice to have some indicator when the API is used improperly.
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.
To my knowledge node has no logger. Logging to stdout/stderr tends to break command line tools.
But I think we should find a way how to deprecate something in NAPI in a way more visible to users like comments in doc.
I think a compile time warning like it is used for node::MakeCallback would be great.
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 a compile time warning like it is used for node::MakeCallback would be great.
AFAICT, it is not possible to emit compile-time warning without changing the API shapes. i.e. the signature of node::MakeCallback was migrated to the one with an additional parameter async_context. Though in the case of n_api, the deprecation is the parameter in the middle of the parameter list. So a new n-api function without the parameter will be required and the one existing can be deprecated.
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
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
instead of emit async init with receiver of the callback.
777e9b5
to
6ccd5a8
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Landed in 5da2512...3a7537d |
Refs: nodejs/node#32930 PR-URL: nodejs/node#49180 Reviewed-By: Chengzhong Wu <legendecas@gmail.com> Reviewed-By: Michael Dawson <midawson@redhat.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Refs: nodejs/node#32930 PR-URL: nodejs/node#49180 Reviewed-By: Chengzhong Wu <legendecas@gmail.com> Reviewed-By: Michael Dawson <midawson@redhat.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
instead of emitting async init with the receiver of the callback.
Fixes: #32898
Related: #32928
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes