N-API: no ability to schedule work on different thread? (via uv_async_t)

[gpean]

Correct me if I'm wrong, but I didn't see a way to schedule work on a different thread using N-API, and/or a way to notify the main loop that some work is done from some other thread and that we need to wake up with a callback call (via uv_async_t and a persistent callback).

I think that's a major use case of native modules (doing stuff in // of the JS thread), so it's kind of surprising. What was the rationale during N-API design?

I was able to hack something using v8.h and uv.h, of course. But it kinda defeats the purpose of having a portable API.

[mscdex]

/cc @nodejs/n-api

[gpean]

(AFAIK napi_create_async_work allows to queue uv work to the default loop - it does not really offload actual work to a separate thread - it just fills the JS thread with more work, although it's native work)

[mscdex]

Looking at the code now, napi_create_async_work()/napi_queue_async_work() utilize uv_work_t and uv_queue_work() behind the scenes. uv_queue_work() enqueues a task to the libuv thread pool, so the napi_async_execute_callback value you pass to napi_create_async_work() will be executed in a separate thread when a thread becomes available. The napi_async_complete_callback value will be called from the main thread after the work thread callback is finished.

[jasongin]

At this time, it is not a goal for N-API to cover all of the functionality offered by libuv. We're certainly open to feedback about this; it's possible we don't have quite the right balance.

We (the N-API working group) discussed extensively how much of libuv should be covered, if any at all. Since libuv is a C API and has infrequent major-version updates, it is already a very stable API (unlike V8 which tends to make breaking changes often). And any forks of Node are likely to still use libuv even if they swap out the JS engine. So, there is clearly less need for the N-API abstraction there.

What we settled on for now was to just include basic async functionality in N-API, because it can be a little tricky to get right without some higher-level abstractions. The N-API async APIs (and the Napi::AsyncWorker class that uses those APIs) are meant to provide a migration path from NAN's AsyncWorker. The NAN APIs also do not allow scheduling work on a different thread. We are assuming that the functionality offered by NAN is good enough for most native addons. Addons that need more advanced threading capabilities can use the libuv APIs directly, as they always have.

I was able to hack something using v8.h and uv.h, of course. But it kinda defeats the purpose of having a portable API.

Why did you need v8.h? As explained above, the expectation is that you should be able to mix in just libuv APIs for that purpose, while still using N-API instead of V8 for everything else.

[mscdex]

The NAN APIs also do not allow scheduling work on a different thread.

Doesn't Nan::AsyncQueueWorker do this?

[jasongin]

Nan::AsyncQueueWorker() uses the uv default loop. napi_queue_async_work() does also.

[mscdex]

Ok, I guess I'm confused about what's being asked then. I thought @gpean was looking to do work on another thread, which those methods do (in the libuv thread pool).

[jasongin]

I think the issue is that Node also uses the uv default loop as its main event loop.

[gpean]

Looking at the code now, napi_create_async_work()/napi_queue_async_work() utilize uv_work_t and uv_queue_work() behind the scenes. uv_queue_work() enqueues a task to the libuv thread pool, so the napi_async_execute_callback value you pass to napi_create_async_work() will be executed in a separate thread when a thread becomes available.

I was not very familiar with libuv and the builtin thread pool you mention - I just read http://docs.libuv.org/en/v1.x/threadpool.html. One issue I see is that you cannot control the pool size other than via an environment variable? It also still competes with the JS work and operations, since this is the same loop. But, I agree it covers most of the use cases for async work.

There can still be use cases where a native library you want to integrate already has its threading done, or you don't want to use the libuv thread pool, and you might just want to notify JS when stuff is available, using uv_async_t. Not the majority of use cases, but still a valid and broad use case IMO.

RE why you need to include v8.h: you won't be able to get a napi_env from the uv_async callback- You have to use v8 API to get the current Isolate, and cast that into a napi_env, basically. We would need a napi_get_current_env or similar?

[gpean]

Said otherwise, the issue I see is that, napi_create_reference allows to persist a value, and I can use that to persist the JS callback function that the uv_async callback should call later. But, it's not possible persist the napi_env alongside with the persisted JS callback, and there is no function to get the current env (isolate), either.

[mhdawson]

@gpean is the need to schedule work on a separate thread for an existing module or something new ?

[mhdawson]

Adding to @jasongin comments we only included coverage for the use case provided by AsyncWorker as it seemed to be broadly used in existing modules. If there is another pattern that is also broadly used in the existing modules we can take a look. Best way to start would be a list of modules that use the additional pattern.

[gpean]

@mhdawson it's for new stuff

I propose that we focus on the following, non major, actionable issues:

• No way to get current isolate/current napi_env (see my last comment) prevents extending functionality through libuv

• No way to use napi_queue_async_work with something else than the default uv loop prevents using the existing async API really asynchronously from JS initiated work (so, not so async)