N-API feature request: expose API to resolve promises asynchronously without napi_create_async_work

[rolftimmermans]

My use case: I have a socket that I'm polling with libuv uv_poll_t. When an event is present I want to resolve a promise.

Calling napi_resolve_deferred() does not work for me because it does not appear to run microtasks.

Looking at the test added in this commit I need to use the following code before resolving the promise.

v8::Isolate* isolate = v8::Isolate::GetCurrent();
v8::HandleScope scope(isolate);
node::CallbackScope callback_scope(isolate, v8::Object::New(isolate), {0, 0});

// resolve promise here

This works perfectly; but now I am required to pull in both v8.h and node.h. It would be nice if there were N-API method to resolve promises with napi_resolve_deferred() asynchronously.

Note that I am not able to use napi_create_async_work()/napi_queue_async_work() for the async code in this case.

[mhdawson]

I spent some time looking at this today and have a first cut at api additions in this branch:https://github.com/mhdawson/io.js/tree/promise_resolve

It adds:

napi_open_callback_scope
napi_close_callback_scope

And this is some test code that I've been working with:

  napi_callback_scope scope = NULL;
  napi_value return_string;
  NAPI_CALL(env, napi_create_string_utf8(env,
                                         "Done",
                                         NAPI_AUTO_LENGTH,
                                         &return_string));
  napi_value resource_name;
  NAPI_CALL(env, napi_create_string_utf8(
      env, "test", NAPI_AUTO_LENGTH, &resource_name));

  napi_async_context context;
  NAPI_CALL(env, napi_async_init(env, NULL, resource_name, &context));

  napi_value resource_object;
  NAPI_CALL(env, napi_create_object(env, &resource_object));

  promise_ran = false;
  NAPI_CALL(env, napi_open_callback_scope(env,
                                          resource_object,
                                          context,
                                          &scope));

  NAPI_CALL(env, napi_resolve_deferred(env, deferred, return_string));

  NAPI_CALL(env, napi_close_callback_scope(env, scope));

What I don't quite have yet is a way to test it out properly. @rolftimmermans can you take a look and fill in a bit more info about what would make a good test to add to our addons-napi test suite.

Note that I did not incorporate the open/close of a handle scope it open/close callback so if there is not one already in force that would need to be added to the code shown above.

[mhdawson]

The other thing I'd want to poke to get a bit more detail at is why napi_create_async_work()/napi_queue_async_work() cannot be used.

[rolftimmermans]

I'll have a look soon to see how this fits in my code.

The reason napi_create_async_work()/napi_queue_async_work() is not adequate is that the promise will be resolved by polling on a socket (with libuv and uv_poll_t). So it's not a pattern that fits into the idea of doing a fixed amount of work and then resolve a promise afterwards.

[mhdawson]

Just wondering if scheduling aysnc work, doing the fixed amount of work and then scheduling another async work for the next time has issues ?

[mhdawson]

Possibly related, also with suggested API addition #13512

[mhdawson]

Sorry looks like I had the wrong branch in the post above. Looking for the right one now.

[mhdawson]

I think I had the write branch may just not have add changes. Will recreate.

[mhdawson]

So new branch is here: https://github.com/mhdawson/io.js/tree/callback_scope (top commit). Working towards a PR as @addaleax suggested it would be good to expose this. @rolftimmermans would still like your input as to whether is addresses your use case.

It has tests which are the ported versions from the non-N-API addon tests, but test-async-hooks.js is failing for some reason. The correct async id is not passed to the registered hook. From some initial investigation it seems to be ok when the node::CallbackScope object is created inside of napi_open_callback_scope , but is not correct when emitBeforeScript is called.

I'm still investigating but @addaleax if you have any suggestions off the top of your head from the symptoms please let me know.

[rolftimmermans]

This seems to be working fine, thanks! With this change I am able to build the project without including v8.h (I think I still need node.h for node::AtExit, but that's another matter).

The test suite passes. I'll try to see if I manage to break it if I try hard enough, but for now it's looking good.

The C-API wasn't very ergonomic to use, but I imagine that can be solved in the node-addon-api project.