napi_create_threadsafe_function func should be optional

[josephg]

Short version:

The func parameter to napi_create_threadsafe_function(env, func, ...) should be optional if you pass a custom call_js_cb function. Not all uses of threadsafe_function use a static javascript function across all invocations.

---

I'm porting the foundationdb bindings to n-api. FDB creates a network thread on which it returns values. So, the normal usage is:

• Javascript calls FDB function (main thread)
• C code creates FDB future object (main thread)
• FDB resolves the future and calls a callback (FDB network thread).
• ???
• Resolved future object is passed back to javascript (main thread)

I'm writing code to solve the missing piece. The current implementation creates a uv_async object each time. But that won't work with napi.

So I need to use napi_create_threadsafe_function(env, func, ...) to send the future value back to the main thread. Each time the future resolves (each item added to the queue) will resolve using its own callback function or future. For this reason I'm passing NULL as the func argument, and using my own resolver code.

But this makes the call to napi_create_threadsafe_function throw a napi_invalid_arg error! The func argument should to be optional if you specify your own call_js_cb callback. I'm working around it for now by making a junk function but thats ugly and gross.

The nodejs code is here, though we'll want to backport the equivalent change to node v10/11 as well. This change should be backwards compatible, because passing null was previously invalid in all cases.

[mhdawson]

@gabrielschulhof FYI. Making it optional seems reasonable to me if it is not required for all use cases.

[gabrielschulhof]

@mhdawson sounds reasonable.

[legendecas]

What about the func argument could be any JS value (undefined, object, anything)? Since there is no actual usage on the value except the case of no custom call_js_cb given. One might be concerning on the semantic change of napi_create_threadsafe_function.

[josephg]

Sounds fine to me!

[bnoordhuis]

Closing, this was fixed in #27791.