worker: improve integration with native addons

[addaleax]

Native addons are now unloaded if all Environments referring to it
have been cleaned up, except if it also loaded by the main Environment.

/cc @gabrielschulhof Who I remember had some suggestions for improving upon this approach

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• commit message follows commit guidelines

[nodejs-github-bot]

@addaleax build started: https://ci.nodejs.org/blue/organizations/jenkins/node-test-pull-request-lite-pipeline/detail/node-test-pull-request-lite-pipeline/1159/pipeline

[richardlau]

Does this need updates to the docs? I'm assuming it only applies to context-aware addons: https://github.com/nodejs/node/blob/master/doc/api/addons.md#context-aware-addons

[addaleax]

@richardlau I’ve updated the documentation a bit (and added the WIP label here, this isn’t fully working yet)

[Trott]

@addaleax Still working on this?

[gabrielschulhof]

@addaleax I don't believe we should be storing dlopen handles in an associative array where the key is the file name. We should just perform a dlopen() every time we need a module, and dlclose all the handles we've collected in an environment when we clean up the environment. The reason is that internally dlopen() already has an associative array where the key is the file name and thus it already caches the handles and increases a given handle's refcount if dlopen() is called again and the corresponding .so is already mapped into the process.

Thus, I believe it is sufficient to add a cleanup hook when the environment is first created which simply closes all the handles which accumulate during the life cycle of that environment. If any of the addons add their own environment cleanup hooks, as advised in the documentation, then those will fire before the one that closes all the handles.

So, I guess this also means that we should probably be storing the list of modules that were loaded into an environment on that environment so that the cleanup hook will find them when it fires.

[gabrielschulhof]

This should be NODE_MODULE_CONTEXT_AWARE because Initialize makes use of the context.

[gabrielschulhof]

This is a pretty strong change in behaviour. NODE_MODULE and even NODE_MODULE_CONTEXT_AWARE were so far expected to fail to register a second time around. Developers should explicitly move to modules that can be loaded multiple times by replacing those two macros with NODE_MODULE_INIT(/*exports, module, context*/) {...} as per our docs, while ensuring that they address the concerns raised there.

If we require that modules move to NODE_MODULE_INIT then that's another reason we don't need to store dlopen handles in a file-name-keyed table.

[Trott]

Needs a rebase.

[addaleax]

This has been superseded by @gabrielschulhof’s #24861 :)