镜像站点 · 本页由第三方 GitHub 只读镜像提供,非 GitHub 官方站点,不接受任何登录或凭据输入。前往 github.com
Skip to content

No N-API equivalent for new well-known-symbol loading feature #19845

Description

@gabrielschulhof

@bnoordhuis adds support for loading a module by looking for a well-known symbol if the module fails to self-register in 3828fc6. The new code looks for a symbol that matches the NODE_MODULE_VERSION (node_register_module_${NODE_MODULE_VERSION}).

We need to extend this approach to N-API modules as well.

Activity

  1. addaleax commented on Apr 6, 2018

    @addaleax
    Member

    Does this make sense for N-API? After all, it is supposed to be ABI-stable, so it doesn't need NODE_MODULE_VERSION... or are you suggesting to also look for node_register_module_napi?

  2. gabrielschulhof commented on Apr 6, 2018

    @gabrielschulhof
    ContributorAuthor

    @addaleax with this change, if you call dlopen() twice on the same file, that will now correctly initialize the addon twice, so this change is a step towards having multi-context native modules, in addition to being a step towards having multi-version native modules.

    Fundamentally, if a plain V8 native addon fails to register, it will still have its Init called, if the Init bears the right name. Without additional work, this will not happen if it's a N-API addon.

  3. gabrielschulhof commented on Apr 6, 2018

    @gabrielschulhof
    ContributorAuthor

    @addaleax I guess the fundamental new feature here is that we now have a tool for finding a symbol given a library handle in a way that is supported across all Node.js platforms. One of my first thoughts is that we may want to

    for (size_t version = NAPI_VERSION; version > 0; version--) {
      void *symbol = dlib->GetSymbolAddress((
        std::string("napi") +
        std::to_string(version) +
        "_register_module").c_str());
      if (symbol != nullptr) {
        // Initialize the N-API module
      }
    }

    Some outstanding questions:

    • How do we get the napi[n]_register_module symbols into the modules? Do we modify the definition of NAPI_MODULE()?
    • Since the code for looking up symbols is currently in node.cc, we need control to go over into node_api.cc somehow, because the types napi_value and napi_env are not defined in node.cc, and those are the types that need to be passed into the N-API module initializer. So, how do we get N-API to do its thing?
  4. gabrielschulhof commented on Apr 8, 2018

    @gabrielschulhof
    ContributorAuthor

    Also, #19731 may render this moot, since it allows the re-loading of modules without any special symbol. I just hope we can address all the edge cases of shared library loading in that PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    node-apiIssues and PRs related to Node-API.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions