-
Notifications
You must be signed in to change notification settings - Fork 465
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
Napi::Reference not copyable, but semantically could be copyable #301
Comments
@nodejs/abi-stable-node please comment. |
My interpretation of the reasoning for that default behavior is that if a reference is freely copyable then it's much easier to lose track and leak the referenced value. I intentionally started |
- implement copyable `Holder` holding a `Reference<T>` - implement `Hold` function to hold any `Value` - test using `Async` to demonstrate need of copyable references Refs: nodejs#301
@jasongin I agree that it would not be very clear what copying a Because of this, I thought of the idea of a The idea is to take a |
@jasongin I think this is still an issue that should be considered. Everytime I use lambdas or however need to keep a reference for using it later, I jump back to C-NAPI using If Seen lot's of code where they introduce a new object on heap (e.g. via So they are/have:
|
Did another implementation on this as pro:
contra:
Now this is possible: auto&& ref = Napi::MakeShared(myObj);
std::thread([ref = std::move(ref)]() {
auto&& result = heavyProcessing();
auto&& data = new ts_data{std::move(ref), result};
// target threadsafe_function has to delete data and automatically unref reference
// => wait for `node-addon-api` supporting `napi_*_threadsafe_*` API
napi_call_threadsafe_function(ts_func, data, napi_tsfn_nonblocking);
}); |
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. |
@legendecas will take a look and lead the discussion in a future meeting. |
@legendecas still looking at this one. |
While playing around the Napi::Reference with threading libraries, I'm still hesitant on making Napi::Reference copyable -- it is dangerous and not safe to copying Napi::Reference around not on the creating thread. Most APIs of node-api/node-addon-api are not threadsafe, except those ones of ThreadSafeFunction, like napi_call_threadsafe_function. With C++ object ownership and lifetime management semantics, it is rather burdensome to implement a threadsafe javascript value reference counting. In a conclusion, I didn't figure out a safe solution that node-addon-api could provide. Rather, I find that one of the core problems of the example above is that those callbacks API exposed by node-addon-api can not be non-copyable lambdas. If non-copyable lambdas fit in those APIs, I've submitted #915 to illustrate the solution. |
allow non-copyable callbacks be finalizer parameters Fixes: nodejs/node-addon-api#301 PR-URL: nodejs/node-addon-api#915 Reviewed-By: Michael Dawson <midawson@redhat.com>
allow non-copyable callbacks be finalizer parameters Fixes: nodejs/node-addon-api#301 PR-URL: nodejs/node-addon-api#915 Reviewed-By: Michael Dawson <midawson@redhat.com>
allow non-copyable callbacks be finalizer parameters Fixes: nodejs/node-addon-api#301 PR-URL: nodejs/node-addon-api#915 Reviewed-By: Michael Dawson <midawson@redhat.com>
allow non-copyable callbacks be finalizer parameters Fixes: nodejs/node-addon-api#301 PR-URL: nodejs/node-addon-api#915 Reviewed-By: Michael Dawson <midawson@redhat.com>
Hi,
I don't understand why
Napi::Reference
can't be copied, although forNapi::Error
it is allowed, implemented as protected. From technical point of view, the C-API allows create multiple reference holders of one value. When using lambdas captures we need copyable types.Look at the following example. A 3rd party lib allocates some memory we want to store in an
Napi::External
with a finalizer. We need to reference handle to overlive lambda where it is freed and after handle is unreferenced.I think we should make
Napi::Reference
copyable.What do you think?
Best Regards
Philipp
The text was updated successfully, but these errors were encountered: