Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

threadsafe: RunInNodeThread #413

Closed
DaAitch opened this issue Dec 25, 2018 · 6 comments
Closed

threadsafe: RunInNodeThread #413

DaAitch opened this issue Dec 25, 2018 · 6 comments
Labels

Comments

@DaAitch
Copy link
Contributor

DaAitch commented Dec 25, 2018

Beside wrapping napi_*_threadsafe I'd also love to see a RunInNodeThread implementation in node-addon-api as an enabler for "concurrent processing" / multithreading and modern C++ with NAPI.

As napi_threadsafe.. API is not fire and forget, but creates objects etc., I wrapped everything in a class which must live on the heap, but threadsafe objects are created once and reused.

The main idea is that we can run RunInNodeThread from any thread:

void js_fn(const Napi::CallbackInfo& info) {
  // persist callback info[0]
  std::thread([cb_ref]() { // or a thread pool or Rx
    int result = heavyProcessing();
    RunInNodeThread([result, cb_ref](Napi::Env env) {
      // callback cb_ref with result in node thread
    });
  }
}

What do you think?

@github-actions
Copy link
Contributor

This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.

@mhdawson
Copy link
Member

We should keep this open, team will try to review so we can discuss in next weeks meeting.

@mhdawson
Copy link
Member

Discussed in the team meeting today. It seems useful, but might fit better in a supporting library and would be a good candidate if we had one that we used to provide wrapper type functions. Unfortunately we don't have that yet.

@mhdawson
Copy link
Member

We discussed again in todays meeting and the what we agreed:

  • We don't want to pull to much into node-addon-api beyond being a wrapper around the C API, we already have a few different higher level wrappers (PRs like this one) for the Threadsafe function and don't think it would make sense to pull them all in.
  • We talked about creating a new organization which groups extras for Node-api and in cases like this offer a repo in that org, with the expectation that the author would maintain that repo.
  • The alternative is of course that authors just create their own repos and we just have a list in the docs which points to that.

Is one of those something that you'd be interested in?

@mhdawson
Copy link
Member

@DaAitch

@DaAitch
Copy link
Contributor Author

DaAitch commented Feb 12, 2021

@mhdawson I think that's a good idea.
At current I have no idea when I'll have time to contribute, so I'd be happy (if someone is interested in the idea) to continue it and feel free to use any code sample, ideas etc. to contribute.

I'll close this.

@DaAitch DaAitch closed this as completed Feb 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants