-
Notifications
You must be signed in to change notification settings - Fork 28.9k
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: Some issues with the new async cleanup hooks #34715
Comments
@addaleax, please correct me if I'm wrong! |
It should be OK to make this change because the async cleanup hooks APIs are still |
That would require bringing closures into C99 :) The argument that we could potentially elide is Also, this isn’t relevant for wrapper APIs in high-level languages like C++ or Rust where the callback would be represented as a closure anyway. |
Also: That’s correct, but the addon author should notice pretty quickly that their tests are broken if they don’t. |
@addaleax widening the scope a bit.
|
@gabrielschulhof Quoting the docs (emphasis added by me):
|
@addaleax Oh, sorry! Should've looked closer! |
@gabrielschulhof mentioned that we could close the issue. |
@mhdawson sorry, another question came to mind for @addaleax so I'm reopening: @addaleax would the async cleanup hooks still function correctly if we modified the sequence of handling them as follows? "Before" is the way it is currently done in the test (AFAICT), whereas "After" is what I'm thinking about:
If so, we can change the API to make receiving the I guess the basic question is this: Must there be an event loop iteration between calling There is also a simpler sequence for closing an a priori handle the async cleanup hooks should address. This is how I imagine my modification would change the way that use case is addressed:
WDYT? |
It should work the same.
I still don’t see how that’s noticeably better – the addon has to do one specific thing, and whether that’s
Keep in mind that that changes the internals quite a bit, as
No, calling |
I’ve also renamed the title as otherwise this sounds as if it were about async hooks :) |
AFAICT currently the add-on must store |
* 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 <gabriel.schulhof@intel.com>
* 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 <gabriel.schulhof@intel.com> Co-authored-by: Anna Henningsen <github@addaleax.net> PR-URL: #34819 Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: Zeyu Yang <himself65@outlook.com>
* 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 <gabriel.schulhof@intel.com> Co-authored-by: Anna Henningsen <github@addaleax.net> PR-URL: #34819 Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: Zeyu Yang <himself65@outlook.com>
At
node/src/node_api.h
Line 257 in bcfb176
cbarg
is a pointer passing from the core into the add-on. The core expects that it will be passed back into the core as the first parameter tocb
. There is no guarantee that add-on authors will faithfully pass it back as expected.We should create a wrapper that retains
cbarg
in the implementation, making it possible to give a function `void (*cb)() to the add-on.The text was updated successfully, but these errors were encountered: