Uh oh!
There was an error while loading. Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork 34.2k
n-api: re-implement async env cleanup hooks#34819
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: re-implement async env cleanup hooks #34819
Uh oh!
There was an error while loading. Please reload this page.
Conversation
nodejs-github-bot commented Aug 18, 2020
Review requested:
|
doc/api/n-api.md Outdated
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 removed the need to pass napi_env here because we wish to discourage JS execution in environment cleanup hooks and this way it should prevent add-ons from having to store the env for the sole purpose of calling this function from a uv_close callback.
We store napi_env internally and it's guaranteed to be usable for the lifetime of a remove_handle, because we Ref() it during its construction and Unref() it asynchronously during its destruction.
addaleax left a comment
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.
As mentioned in the issue, I'm missing the motivation for this change here.
I, personally, feel like the previous interface was a bit clearer because the signature of the cleanup hook implied that the callback function needed to be called.
In any case, the documentation needs to be updated with changes: sections.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
doc/api/n-api.md Outdated
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 you're removing the signature here, please add a link to the definition of napi_async_cleanup_hook
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.
Added the link below.
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 do like how this better hides the internal implementation. It seemed like we were leaking a bit more than needed in the N-API APIs wrapping the internal node api.
gabrielschulhof commented Aug 18, 2020
@addaleax I have addressed your review comments. Qualitatively, I think this approach makes I understand that these are all qualitative arguments and, as such, more or less a matter of taste. Quantitatively, perhaps, we can look at the test and see that it is simplified by 18 lines, though, since the change removes support for optional storage of the handle, the six removed lines that tested for that feature should perhaps not be considered. That still leaves 12 lines that are an indication that perhaps using async cleanup hooks by way of this API rather than the previous API results in less add-on code that needs writing and maintaining. |
addaleax commented Aug 18, 2020
@gabrielschulhof I mean, I think any high-level wrapper like the C++ one would expose these two versions the same way anyway :) Ultimately, I'm good with this if you think it's worth the breakage. |
gabrielschulhof commented Aug 19, 2020
This is an overview for those who might wish to review of the current implementation vs. the proposed implementation showing how each would handle the most common use case: |
* Avoid passing core `void*` and function pointers into add-on. * Document `napi_async_cleanup_hook_handle` type. * Render receipt of the handle mandatory. Removal of the handle remains mandatory. Fixes: nodejs#34715 Signed-off-by: Gabriel Schulhof <[email protected]>
Co-authored-by: Anna Henningsen <[email protected]>
5cf1c38 to 6037705Comparegabrielschulhof commented Aug 19, 2020
@addaleax I added the |
himself65 left a comment
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
nodejs-github-bot commented Aug 26, 2020
| node::RemoveEnvironmentCleanupHook(std::move(remove_handle->handle)); | ||
| delete remove_handle; | ||
| if (remove_handle == nullptr) |
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 it can still be optional to get the handle when the hook is added. When the hook is called it is passed the handle so unless it wants to call remove before the hook runs, it does not need to get/store the handle. I'd suggest we change back to this being optional.
mhdawson left a comment
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 after being updated to make getting the handle on additional optional like it was before.
mhdawson commented Aug 26, 2020
The assumption is that there should be little to no usage of the existing API as it's only be out for ~ 3weeks from what Gabriel tells me and as an Experimental API would should be able to change it in this case. |
gabrielschulhof commented Aug 26, 2020 • edited
Loading Uh oh!
There was an error while loading. Please reload this page.
edited
Uh oh!
There was an error while loading. Please reload this page.
@mhdawson it is once more optional to receive and store the handle during creation. It is nevertheless still mandatory to store the handle when receiving it in the cleanup hook, because it must be passed to This actually reduces the breakage slightly because the first step is now identical to the current implementation. |
gabrielschulhof commented Aug 26, 2020
Please mind the edit above, sorry:
|
nodejs-github-bot commented Aug 26, 2020
0f4da9b to 5b694e4Comparenodejs-github-bot commented Aug 27, 2020
mhdawson left a comment
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
gabrielschulhof commented Aug 27, 2020
Landed in 0848f56. |
* Avoid passing core `void*` and function pointers into add-on. * Document `napi_async_cleanup_hook_handle` type. * Render receipt of the handle mandatory from the point where the hook gets called. Removal of the handle remains mandatory. Fixes: #34715 Signed-off-by: Gabriel Schulhof <[email protected]> Co-authored-by: Anna Henningsen <[email protected]> PR-URL: #34819 Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Zeyu Yang <[email protected]>
* Avoid passing core `void*` and function pointers into add-on. * Document `napi_async_cleanup_hook_handle` type. * Render receipt of the handle mandatory from the point where the hook gets called. Removal of the handle remains mandatory. Fixes: #34715 Signed-off-by: Gabriel Schulhof <[email protected]> Co-authored-by: Anna Henningsen <[email protected]> PR-URL: #34819 Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Zeyu Yang <[email protected]>
* Avoid passing core `void*` and function pointers into add-on. * Document `napi_async_cleanup_hook_handle` type. * Render receipt of the handle mandatory from the point where the hook gets called. Removal of the handle remains mandatory. Fixes: #34715 Signed-off-by: Gabriel Schulhof <[email protected]> Co-authored-by: Anna Henningsen <[email protected]> PR-URL: #34819 Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Zeyu Yang <[email protected]>
void*and function pointers into add-on.napi_async_cleanup_hook_handletype.mandatory.
Fixes: #34715
Signed-off-by: Gabriel Schulhof [email protected]
Checklist
make -j4 test(UNIX), orvcbuild test(Windows) passes