-
Notifications
You must be signed in to change notification settings - Fork 464
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
Is it possible to determine the type of an NAPI::Object in a non-global context? #764
Comments
Object.InstanceOf ends up calling napi_status napi_instanceof(napi_env env,
napi_value object,
napi_value constructor,
bool* result) {
NAPI_PREAMBLE(env);
CHECK_ARG(env, object);
CHECK_ARG(env, result);
*result = false;
v8::Local<v8::Object> ctor;
v8::Local<v8::Context> context = env->context();
CHECK_TO_OBJECT(env, context, ctor, constructor);
if (!ctor->IsFunction()) {
napi_throw_type_error(env,
"ERR_NAPI_CONS_FUNCTION",
"Constructor must be a function");
return napi_set_last_error(env, napi_function_expected);
}
napi_status status = napi_generic_failure;
v8::Local<v8::Value> val = v8impl::V8LocalValueFromJsValue(object);
auto maybe_result = val->InstanceOf(context, ctor);
CHECK_MAYBE_NOTHING(env, maybe_result, status);
*result = maybe_result.FromJust();
return GET_RETURN_STATUS(env);
} I assume the problem is that mismatch between the context that was active when the env was created and the context active when the call is made. @gabrielschulhof, @addaleax some methods call I'm wondering if for napi_instanceof we should be using |
Yes. The
Currently, this is irrelevant because Node.js is not actually supporting multi-Context addons. Once we do, using (For the most part, passing a context to V8 functions is relevant for cases in which a new Error object is being thrown – e.g. because the right-hand side isn’t a constructor.)
|
Thanks for the clarification on contexts. Would you agree that the 2 places we |
I think that would be fine, yes. |
In summary, it sounds like proper support for native add-ons to correctly support |
@jschlight I think this has been answered, is it ok to close ? |
Refs: nodejs/node-addon-api#764 Improve the consistency of how we get a context when needed. We generally used env->context() in N-API but there were are few exceptions that this PR addresses. Signed-off-by: Michael Dawson <[email protected]>
Refs: nodejs/node-addon-api#764 Improve the consistency of how we get a context when needed. We generally used env->context() in N-API but there were are few exceptions that this PR addresses. Signed-off-by: Michael Dawson <[email protected]> PR-URL: #36068 Reviewed-By: Juan José Arboleda <[email protected]> Reviewed-By: Gabriel Schulhof <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Chengzhong Wu <[email protected]>
Refs: nodejs/node-addon-api#764 Improve the consistency of how we get a context when needed. We generally used env->context() in N-API but there were are few exceptions that this PR addresses. Signed-off-by: Michael Dawson <[email protected]> PR-URL: #36068 Reviewed-By: Juan José Arboleda <[email protected]> Reviewed-By: Gabriel Schulhof <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Chengzhong Wu <[email protected]>
Yes @mhdawson Thanks for the ping. |
Refs: nodejs/node-addon-api#764 Improve the consistency of how we get a context when needed. We generally used env->context() in N-API but there were are few exceptions that this PR addresses. Signed-off-by: Michael Dawson <[email protected]> PR-URL: #36068 Reviewed-By: Juan José Arboleda <[email protected]> Reviewed-By: Gabriel Schulhof <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Chengzhong Wu <[email protected]>
Refs: nodejs/node-addon-api#764 Improve the consistency of how we get a context when needed. We generally used env->context() in N-API but there were are few exceptions that this PR addresses. Signed-off-by: Michael Dawson <[email protected]> PR-URL: #36068 Reviewed-By: Juan José Arboleda <[email protected]> Reviewed-By: Gabriel Schulhof <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Chengzhong Wu <[email protected]>
Refs: nodejs/node-addon-api#764 Improve the consistency of how we get a context when needed. We generally used env->context() in N-API but there were are few exceptions that this PR addresses. Signed-off-by: Michael Dawson <[email protected]> PR-URL: #36068 Reviewed-By: Juan José Arboleda <[email protected]> Reviewed-By: Gabriel Schulhof <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Chengzhong Wu <[email protected]>
This question is related to an interesting issue raised on the
node-sqlite3
project:TryGhost/node-sqlite3#1355
The JavaScript code from the issue looks like:
The pertinent code using
node-addon-api
looks like:The code to determine if
source
is aDate
object is failing apparently becausesource
has been allocated outside the global context.The author of the
node-sqlite3
issue has identified theIsDate
method as a way to address this issue. But is there another more general approach that would work to identify type of an NAPI::Object in a non-global context?The text was updated successfully, but these errors were encountered: