node::MakeCallback(), napi_make_callback() requires recv to be an object / not empty #26342

Activity

1. bnoordhuis

   added

   questionIssues asking questions about Node.js.Issues asking questions about Node.js.

   addonsIssues and PRs related to native addons.Issues and PRs related to native addons.

   on Feb 28, 2019
2. bnoordhuis commented on Feb 28, 2019

   

   bnoordhuis

   on Feb 28, 2019

   Member

   More actions

   node::MakeCallback() requiring an object as the receiver has been true ever since its inception because it predates strict mode.

   napi_make_callback() is a thin wrapper around node::MakeCallback() and therefore inherits that restriction.

   That restriction cannot be lifted unconditionally because e.g. domain callbacks (as in: require('domain').create()) are closely tied to node::MakeCallback() and expect that the receiver is an object.

   If we end up with something where it's technically possible to omit the receiver but practically speaking it's not, then we might as well leave well enough alone.
3. simonbuchan commented on Feb 28, 2019

   

   simonbuchan

   on Feb 28, 2019

   Author

   More actions

   Thanks for the reply! The workaround I'm using now is (trimmed for readability):

   napi_value context_object, recv;
   napi_create_object(env, &context_object);
   napi_get_undefined(env, &recv);
   
   napi_open_callback_scope(env, context_object, async_context, &callback_scope);
   
   napi_call_function(env, recv, func, ...);

   Which seems to work fine, as the context object is decoupled from the receiver. I don't really understand why the context object exists, or how domains affect this, is this dumb and wrong?
4. addaleax commented on Feb 28, 2019

   

   addaleax

   on Feb 28, 2019

   Member

   More actions

   @simonbuchan context_object should ideally match what was passed to napi_async_init.

   The tl;dr is: It’s not currently used in napi_open_callback_scope. But a number of people think that the async_hooks API should be changed to not use integer IDs to refer to async resources, and that the resource objects themselves should be used for identifying asynchronous resources. In that case we’d need the napi_open_callback_scope() argument.

   See e.g. #21313 for a previous attempt at moving into this direction – I don’t know if @mcollina is still interested in changing the async_hooks API to address this?
5. simonbuchan commented on Feb 28, 2019

   

   simonbuchan

   on Feb 28, 2019

   Author

   More actions

   Hmm, If I understand what you mean, @addaleax this would mean the async_hooks callbacks could later look something like { init(...), before(id, resource), after(id, resource), destroy(id, resource) } (note extra resource args) and as napi_async_init()/_destroy() are tied to the init and destroy events, napi_open/close_callback_scope() are tied to before and after events, and thus the context_object values should match so a async_hooks client can compare resource instances instead of ids?

   If that's intended, I would have expected node to be stashing the context_object in the napi_async_context so you can't pass the "wrong" value later, but maybe it's just some wiggle room for you guys.

   I don't currently have a meaningful "context" instance, but it seems a simple napi_create_object() is good enough for identity, and maybe I can use something more meaningful later (in my usage, though, when "init" and "destroy" should happen is a bit ambiguous...)
6. mcollina commented on Feb 28, 2019

   

   mcollina

   on Feb 28, 2019

   SponsorMember

   More actions

   See e.g. #21313 for a previous attempt at moving into this direction – I don’t know if @mcollina is still interested in changing the async_hooks API to address this?

   Let's what the diagnostics summit.

   cc @nodejs/diagnostics
7. jasnell commented on Jun 26, 2020

   

   jasnell

   on Jun 26, 2020

   Member

   More actions

   ping @nodejs/n-api @nodejs/addon-api ... is there anything actionable here?
8. mhdawson commented on Jul 3, 2020

   

   mhdawson

   on Jul 3, 2020

   Member

   More actions

   I don't think any changes are planned.
9. mhdawson commented on Nov 15, 2021

   

   mhdawson

   on Nov 15, 2021

   Member

   More actions

   I'm closing this since there has been no follow up questions since my comment over a year ago. Please let us know if you think that was not the right thing to do.
10. mhdawson

    closed this as completedon Nov 15, 2021