Skip to content
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

Conversation

gabrielschulhof
Copy link
Contributor

@gabrielschulhof gabrielschulhof commented Apr 3, 2017

  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

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • commit message follows commit guidelines
Affected core subsystem(s)

napi

@nodejs-github-bot nodejs-github-bot added the c++ Issues and PRs that require attention from people who are familiar with C++. label Apr 3, 2017
@gabrielschulhof
Copy link
Contributor Author

The original PR against abi-stable-node (for reference): nodejs/abi-stable-node#208

@vsemozhetbyt vsemozhetbyt added addons Issues and PRs related to native addons. node-api Issues and PRs related to the Node-API. labels Apr 3, 2017
@gabrielschulhof
Copy link
Contributor Author

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;
};
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Member

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.

Copy link
Member

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.

Copy link
Contributor Author

@gabrielschulhof gabrielschulhof Apr 4, 2017

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.

Copy link
Contributor Author

@gabrielschulhof gabrielschulhof Apr 4, 2017

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.

Copy link
Member

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.

Copy link
Member

@addaleax addaleax left a 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)

@gabrielschulhof
Copy link
Contributor Author

gabrielschulhof commented Apr 4, 2017

@addaleax sorry! Had some trouble moving to the upstream repo!

@gabrielschulhof gabrielschulhof force-pushed the 198-per-module-environment branch from 8e34f29 to 6985ed4 Compare April 4, 2017 05:33
@gabrielschulhof
Copy link
Contributor Author

@addaleax should be good now.

Copy link
Member

@mhdawson mhdawson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@mhdawson
Copy link
Member

mhdawson commented Apr 4, 2017

@mhdawson
Copy link
Member

mhdawson commented Apr 5, 2017

Unfortunately this conflicts with the changes I just landed, can you rebase and then I'll land right away

@gabrielschulhof
Copy link
Contributor Author

@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
@gabrielschulhof gabrielschulhof force-pushed the 198-per-module-environment branch from 6985ed4 to 09900a6 Compare April 5, 2017 19:23
@gabrielschulhof
Copy link
Contributor Author

@mhdawson done.

@mhdawson
Copy link
Member

mhdawson commented Apr 5, 2017

@mhdawson mhdawson self-assigned this Apr 5, 2017
@mhdawson
Copy link
Member

mhdawson commented Apr 5, 2017

CI green, landed as 0a5bf4a

mhdawson pushed a commit that referenced this pull request Apr 5, 2017
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>
@mhdawson mhdawson closed this Apr 5, 2017
@gabrielschulhof gabrielschulhof deleted the 198-per-module-environment branch April 5, 2017 22:12
mhdawson added a commit to mhdawson/io.js that referenced this pull request Apr 13, 2017
remove code that is no longer used after
  n-api: create napi_env as a real structure
  nodejs#12195
@mhdawson mhdawson mentioned this pull request Apr 13, 2017
2 tasks
@jasnell jasnell mentioned this pull request May 11, 2017
gabrielschulhof pushed a commit to gabrielschulhof/node that referenced this pull request Apr 10, 2018
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>
MylesBorins pushed a commit that referenced this pull request Apr 16, 2018
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>
@MylesBorins MylesBorins mentioned this pull request Apr 16, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
addons Issues and PRs related to native addons. c++ Issues and PRs that require attention from people who are familiar with C++. node-api Issues and PRs related to the Node-API.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Last exception should be per-isolate
7 participants