-
Notifications
You must be signed in to change notification settings - Fork 30k
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: create napi_env as a real structure #12195
napi: create napi_env as a real structure #12195
Conversation
The original PR against abi-stable-node (for reference): nodejs/abi-stable-node#208 |
That original PR had already received th LGTM from @addaleax. |
v8::Isolate* isolate; | ||
v8::Persistent<v8::Value> last_exception; | ||
napi_extended_error_info last_error; | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm thinkintg the base napi_env__ class should be independant of the implementation. It would then be extended by implementations to add specifics like the isolate. In that way the contract would be clear and we later want to stash some vm independent info in the base env we can do that and it would flow automatically into the implementations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some implementations may be written in C, so I think the lowest common denominator is the pointer to the struct/class napi_env__, which is defined as napi_env
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think I got my point across quite right. What I meant was that we may want to add elements to the napi env structure which are not related to the implementation (v8, chackra) and have it setup so that the we can do that so that the implementations can just inherit those changes would be good.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having said that, if that is not straight forward we can defer to a later PR. If you believe thats the case just let me know as the change looks good to me other than that suggestion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure what we could provide to implementations. For example, last_exception
only exists in the V8 implementation because in ChakraCore napi_get_and_clear_last_exception()
goes straight through to JSRT, so we likely won't need to store any last exception on the env
in the ChakraCore implementation.
Of course, we could come up with an API for implementors, wherein we might expose the minimal definition of napi_env__
for them to extend, but I think that's a substantial exercise.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interestingly though, in my WIP Zephyr.js implementation (updated the link to point to the definition of struct napi_env__
) I also store the last exception on the env.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since it seems like it requires more thought, lets proceed with the PR as is and we can revise if/when we think it through further.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM but the comments from nodejs/abi-stable-node#208 (review) still apply (indentation in the addon and maybe a check that the napi_get_value_double
fails)
@addaleax sorry! Had some trouble moving to the upstream repo! |
8e34f29
to
6985ed4
Compare
@addaleax should be good now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Unfortunately this conflicts with the changes I just landed, can you rebase and then I'll land right away |
@mhdawson on it. |
1. We define struct napi_env__ to include the isolate, the last exception, and the info about the last error. 2. We instantiate one struct napi_env__ during module registration and we pass it into the FunctionCallbackInfo for all subsequent entries into N-API when we create functions/accessors/finalizers. Once module unloading will be supported we shall have to delete the napi_env we create during module init. There is a clear separation between public and private API wrt. env: 1. Public APIs assert that env is not nullptr as their first action. 2. Private APIs need not validate env. They assume it's not nullptr. Fixes: nodejs/abi-stable-node#198
6985ed4
to
09900a6
Compare
@mhdawson done. |
CI green, landed as 0a5bf4a |
1. We define struct napi_env__ to include the isolate, the last exception, and the info about the last error. 2. We instantiate one struct napi_env__ during module registration and we pass it into the FunctionCallbackInfo for all subsequent entries into N-API when we create functions/accessors/finalizers. Once module unloading will be supported we shall have to delete the napi_env we create during module init. There is a clear separation between public and private API wrt. env: 1. Public APIs assert that env is not nullptr as their first action. 2. Private APIs need not validate env. They assume it's not nullptr. PR-URL: #12195 Fixes: nodejs/abi-stable-node#198 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
remove code that is no longer used after n-api: create napi_env as a real structure nodejs#12195
1. We define struct napi_env__ to include the isolate, the last exception, and the info about the last error. 2. We instantiate one struct napi_env__ during module registration and we pass it into the FunctionCallbackInfo for all subsequent entries into N-API when we create functions/accessors/finalizers. Once module unloading will be supported we shall have to delete the napi_env we create during module init. There is a clear separation between public and private API wrt. env: 1. Public APIs assert that env is not nullptr as their first action. 2. Private APIs need not validate env. They assume it's not nullptr. PR-URL: nodejs#12195 Fixes: nodejs/abi-stable-node#198 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
1. We define struct napi_env__ to include the isolate, the last exception, and the info about the last error. 2. We instantiate one struct napi_env__ during module registration and we pass it into the FunctionCallbackInfo for all subsequent entries into N-API when we create functions/accessors/finalizers. Once module unloading will be supported we shall have to delete the napi_env we create during module init. There is a clear separation between public and private API wrt. env: 1. Public APIs assert that env is not nullptr as their first action. 2. Private APIs need not validate env. They assume it's not nullptr. Backport-PR-URL: #19447 PR-URL: #12195 Fixes: nodejs/abi-stable-node#198 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
We define struct napi_env__ to include the isolate, the last
exception, and the info about the last error.
We instantiate one struct napi_env__ during module registration and
we pass it into the FunctionCallbackInfo for all subsequent entries into
N-API when we create functions/accessors/finalizers.
Once module unloading will be supported we shall have to delete the
napi_env we create during module init.
There is a clear separation between public and private API wrt. env:
Public APIs assert that env is not nullptr as their first action.
Private APIs need not validate env. They assume it's not nullptr.
Fixes: nodejs/abi-stable-node#198
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
napi