-
-
Notifications
You must be signed in to change notification settings - Fork 31.7k
Interoperability between the v8::External and Napi::External is broken #58480
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
Comments
@nodejs/node-api |
One could argue that the "interoperability between the |
I concur. It's purely self-inflicted. Closing as a wontfix. |
Ok, got it. If the Node_API is not compatible with the V8-API then you might at least make the node-API feature compliant and offer some kind of embedder API as well. Right now there is no embedder API in the Node-API, which is the way why everybody embedding a nodeJS has to make use of the V8-API. |
@NorbertHeusser there are efforts underway support embedding in a way that would be compatible with Node-api. See these PRs Will either of these cover your use case? If not we are interested in understanding if that means there is a gap proposed APIs. |
Thanks for guiding me to the ongoing PRs on the Node-api to offer an embedding API. |
Uh oh!
There was an error while loading. Please reload this page.
Version
20.x 22.x
Platform
Subsystem
No response
What steps will reproduce the bug?
With the merge of PR-51149 the interoperability between the v8::External and the Napi::External API usage is broken.
Create a v8::External value using the v8-API (e.g. from the NodeJS embedder C++ API) and later retrieve the value from an native addon API base Napi::External will not result in the same native pointer.
This way it is no longer possible to provide any native data reference from the embedder API to a native addon function.
How often does it reproduce? Is there a required condition?
It is always happens. Simply create a External value based on one of the APIs and retrieve it using the other API.
E.g. create a External value from the embedder functions:
Retrieve the pointer later from a native addon function:
What is the expected behavior? Why is that the expected behavior?
The expected behavior would be the same native pointer is given back. This worked until Node version 18.x.
With the current implementation it is no longer possible to exchange a nativ C++ pointer between code written based on the v8 API and node addon API.
In my personal view the design issue starts with the v8::External being a simple value in the V8-API. And being a TypeTaggable derived type in the addon API. With the current implementation there is no counterpart to the v8::External value type in the addon API anymore.
What do you see instead?
Creating a v8::External value and retrieve it based on the Napi::External we get a totally different pointer. The Napi::External expects the pointer to point to the internal class Napi::ExternalWrapper. But the v8::External API does not create the Napi::ExternalWrapper instance.
Additional information
We use the the Nodejs embedder API to embedd a nodejs engine into our C++ based application. As there is no node addon embedder API we have to use the node/v8 api in setting up the embedded NodeJS engine.
Additionally we provide some native addon functions to provide access to to data from the surrounding process. As we have multiple NodeJS engines running inside our process we need to find a way to provide access to the inividual C++ object creating a nodeJS instance each. Until node 18.x we used an v8::External value created in the global from the embedder function and were able to retrieve this pointer from within the addon API functions.
Workaround we use now:
The only workaround we found now is to create an v8::ArrayBuffer with the size of the native pointer, Copy the pointer into the arrray buffer. Create a v8::Uint8Array and add this array to global. In this code we have our class Script creating the embedded NodeJS engine.
And in the native addon function copy the pointer back from the Array to get access to the C++ Script instance:
The text was updated successfully, but these errors were encountered: