Is well-known symbol the recommended way to build addon?

[fs-eire]

The change #18934 introduced a new interface enabling addon to initialize itself for multiple context using symbol node_register_module_v${NODE_MODULE_VERSION}.

However I didn't find much more information about this feature:
no related documents on https://nodejs.org/dist/latest-v10.x/docs/api/addons.html;
no examples ( only one simple test );
no related macro definition in node.h;
no n-api equivalent

I think the feature is still in experimental.. will it become a preferred and recommended way for addon, or it just going to be remove in some future version?

[joyeecheung]

cc @bnoordhuis @gabrielschulhof

[gabrielschulhof]

If you go with the well-known symbol approach, you will want to avoid having global static data, because you are committing yourself to supporting multiple loading of your addon. This is desirable. Note that you can perform the following steps to avoid using global static data: 1. Heap-allocate a structure during module init which stores all the data you would normally store in global static variables. 2. Create a weak reference to the exports object which, when called, destroys the structure. 3. Pass the native pointer to each binding you expose to JavaScript. 4. Pass the native pointer to each async callback. Then, in all your bindings you will be able to call `info.Data()` to retrieve the pointer if it's a V8 binding. Similarly, in N-API you can associate data with a binding and it will be returned in argument 6 of `napi_get_cb_info()`. I have created a gist[0] to provide a N-API example. [0] https://gist.github.com/gabrielschulhof/d24c1f66b9f48896318e332d8a756b87

…

On Tue, Jun 12, 2018 at 2:06 PM, Joyee Cheung ***@***.***> wrote: cc @bnoordhuis <https://github.com/bnoordhuis> @gabrielschulhof <https://github.com/gabrielschulhof> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#21291 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA7k0el7EykEYQ1xrI58so82s-cEYXkXks5t8AMWgaJpZM4Uk4Pt> .

[gabrielschulhof]

@joyeecheung I wrote the previous comment wrong. In step 1. I meant to say "... you would normally store in global static variables."

[gabrielschulhof]

@joyeecheung AFAIK currently exports objects are never gc-ed, because we never unload modules. But then again, global static variables aren't de-allocated either, for the same reason.

[gabrielschulhof]

@joyeecheung the N-API documentation on master mentions the macro NAPI_MODULE_INIT under the section Module registration.

[gabrielschulhof]

This has not been back-ported though, AFAIK.

[gabrielschulhof]

@joyeecheung the hello world addon test already tests multiple loading of an addon.

[fs-eire]

thanks @gabrielschulhof for the detailed information.

The steps show HOW to avoid using global static data, but I don't understand WHY should avoid using global static data. Sometimes I want to have a shared state (like a singleton pattern), I believe this scenario is OK to have.

So the good news is, the N-API macro NAPI_MODULE_INIT is already there ready for this kind of scenario. Is it a good idea to create a corresponding macro NODE_MODULE_INIT for the usage?

[gabrielschulhof]

@fs-eire I guess it boils down to whether the global static singleton contains any references to JavaScript values. Since the module may be loaded multiple times from different contexts, and perhaps even different isolates, the JavaScript value(s) stored in the singleton may not be valid. Thus, if you want to have a singleton, it should only contain native data.

NODE_MODULE_INIT() may indeed be worth a PR.