| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
This duplicates a lot of code from AsyncWrap. It also appears to be a major breaking change to N-API which I was hoping to avoid as it makes it difficult to backport executionAsyncResource related code. Not sure how I feel about this. 😟 |
Sorry, something went wrong.
Yes, this is for AsyncWrap not suitable in the case since the resource object in the N-API may have no internal slot, which fails the BaseObject's assertion.
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). |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
Sorry, something went wrong.
There was a problem hiding this comment.
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. 🤔
Sorry, something went wrong.
There was a problem hiding this comment.
Should we perhaps use the resource_object to warn if it's different than the object contained in the AsyncContext?
Sorry, something went wrong.
There was a problem hiding this comment.
@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 */
Sorry, something went wrong.
There was a problem hiding this comment.
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.
Sorry, something went wrong.
There was a problem hiding this comment.
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.
Sorry, something went wrong.
There was a problem hiding this comment.
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.
Sorry, something went wrong.
There was a problem hiding this comment.
LGTM
Sorry, something went wrong.
Sorry, something went wrong.
instead of emit async init with receiver of the callback.
Sorry, something went wrong.
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>
| Back | FazBrowse Home | New Git URL |
instead of emitting async init with the receiver of the callback.
Fixes: #32898
Related: #32928
Checklist