-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
Using v8::Private::ForApi
for N-API object wrapping
#14367
Comments
I'm thinking that we can use this mechanism to attach a hidden property to How kosher is it to attach such hidden properties to the global object? |
@gabrielschulhof I’m not sure how that relates to the issue above, but in any case: That sounds fine as long as you’re aware that Node code can run in different contexts with different globals. |
@addaleax are modules loaded per-context or per-isolate? That is, if there is one isolate with two different contexts, can the same module instance be used in both? The relation to this issue is that ideally, we'd type-check via However, we need to make sure that we never end up with a situation where an instance created from one |
Aha! // FIXME(bnoordhuis) Not multi-context ready. TBD how to resolve the conflict
// when two contexts try to load the same shared object. Maybe have a shadow
// cache that's a plain C list or hash table that's shared across contexts? |
@gabrielschulhof Well, can't comment about the process of dynamic loading from different contexts, but About reusing I don't see any problem with attaching hidden properties to the global object. Not like hidden properties are, you know, visible from JS, or even C++ if the consumer is not actively trying to find it. |
@addaleax under what circumstances does Node create multiple contexts and run JS code in them? |
@gabrielschulhof It’s programatically available in the built-in |
It's also used in projects like electron and nw.js that create a context per tab. |
Store the `napi_env` on the global object at a private key. This gives us one `napi_env` per context. Refs: #14367 PR-URL: #14217 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Timothy Gu <[email protected]>
Store the `napi_env` on the global object at a private key. This gives us one `napi_env` per context. Refs: #14367 PR-URL: #14217 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Timothy Gu <[email protected]>
@gabrielschulhof I think this issue could be closed now, right? |
Actually, `napi_wrap()` isn't using it yet. It's only being used for the
`napi_env` so far.
…On Wed, Aug 9, 2017 at 5:06 AM, Timothy Gu ***@***.***> wrote:
@gabrielschulhof <https://github.com/gabrielschulhof> I think this issue
could be closed now, right?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#14367 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AA7k0cWjB9eUkyYFHtARLc9pnKZnGVjtks5sWRQSgaJpZM4OcyJd>
.
|
PR-URL: #18311 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Fixes: #14367
PR-URL: #18311 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Fixes: #14367
PR-URL: #18311 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Fixes: #14367
Store the `napi_env` on the global object at a private key. This gives us one `napi_env` per context. Refs: nodejs#14367 PR-URL: nodejs#14217 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Timothy Gu <[email protected]>
PR-URL: nodejs#18311 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Fixes: nodejs#14367
PR-URL: nodejs#18311 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Fixes: nodejs#14367
Store the `napi_env` on the global object at a private key. This gives us one `napi_env` per context. Refs: #14367 Backport-PR-URL: #19447 PR-URL: #14217 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Timothy Gu <[email protected]>
Backport-PR-URL: #19447 PR-URL: #18311 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Fixes: #14367
Backport-PR-URL: #19265 PR-URL: #18311 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Fixes: #14367
PR-URL: nodejs#18311 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Fixes: nodejs#14367
Currently, N-API's object wrapping uses
v8::External
with aconst char*
as a brand check. However,v8::External
s are known to be inefficient, and the fact that one suchExternal
is created for every wrapped object only worsens the problem. On the other hand, V8 provides the mechanism necessary for cross-napi_env
brand checks inv8::Private::ForApi
, which is like a C++-private version ofSymbol.for()
, andv8::Object::HasPrivate
/SetPrivate
. Handles to thesev8::Private
s can then be cached pernapi_env
in aPersistent
. Similar features are also available in earlier V8 versions, as implemented in @kkoopa's NAN.I'd be willing to cook up a PR for this.
/cc @nodejs/n-api @gabrielschulhof @jasongin
The text was updated successfully, but these errors were encountered: