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

src: cache necessary isolate & context in api/* #38366

Closed
wants to merge 1 commit into from

Conversation

XadillaX
Copy link
Contributor

Refs: #37473

@nodejs-github-bot nodejs-github-bot added c++ Issues and PRs that require attention from people who are familiar with C++. lib / src Issues and PRs related to general changes in the lib or src directory. needs-ci PRs that need a full CI run. labels Apr 23, 2021
Copy link
Member

@joyeecheung joyeecheung left a comment

Choose a reason for hiding this comment

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

LGTM with a nit

@@ -130,7 +134,7 @@ void InternalCallbackScope::Close() {
return;
}

HandleScope handle_scope(env_->isolate());
HandleScope handle_scope(isolate);
Copy link
Member

Choose a reason for hiding this comment

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

hm, I know this exists before this PR, but why do we create a handle scope here? May be it should just be deleted, AFAICT this is meant to be invoked when there is already a HandleScope

Copy link
Contributor Author

@XadillaX XadillaX Apr 23, 2021

Choose a reason for hiding this comment

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

Copy link
Member

Choose a reason for hiding this comment

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

I mean, just because there’s an outer handle scope doesn’t mean that it’s pointless to have an inner one, e.g. when InternalCallbackScope is used in a loop

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.

@XadillaX The code LGTM, but neither this nor the PR it references have any explanation why we would want to do this…? For contexts I can see the argument that eventually we might have multi-context readiness, but for the Isolate pointer this seems like a fairly pointless change

@@ -130,7 +134,7 @@ void InternalCallbackScope::Close() {
return;
}

HandleScope handle_scope(env_->isolate());
HandleScope handle_scope(isolate);
Copy link
Member

Choose a reason for hiding this comment

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

I mean, just because there’s an outer handle scope doesn’t mean that it’s pointless to have an inner one, e.g. when InternalCallbackScope is used in a loop

@XadillaX
Copy link
Contributor Author

@XadillaX The code LGTM, but neither this nor the PR it references have any explanation why we would want to do this…? For contexts I can see the argument that eventually we might have multi-context readiness, but for the Isolate pointer this seems like a fairly pointless change

Yeah, the context changing is for avoiding multi-times PersistentToLocal. But Isolate is just a handy thing. Shall I change isolate back?

@addaleax
Copy link
Member

Yeah, the context changing is for avoiding multi-times PersistentToLocal.

If you’re saying that this has a performance impact: We use PersistentToLocal::Strong for env->context(), which is essentially just a pointer lookup. This patch is not going to have any significant performance benefits, so it really makes just sense to focus on what’s cleanest from a code readability point of view.

I’m not really minding the code change, but I do think that the project should a) have a common code style for these questions and b) enforce that through a linter, otherwise changes will just happen back and forth forever (#38172 literally did the reverse of this only a week ago).

@XadillaX
Copy link
Contributor Author

Yeah, the context changing is for avoiding multi-times PersistentToLocal.

If you’re saying that this has a performance impact: We use PersistentToLocal::Strong for env->context(), which is essentially just a pointer lookup. This patch is not going to have any significant performance benefits, so it really makes just sense to focus on what’s cleanest from a code readability point of view.

I’m not really minding the code change, but I do think that the project should a) have a common code style for these questions and b) enforce that through a linter, otherwise changes will just happen back and forth forever (#38172 literally did the reverse of this only a week ago).

I see. I think we may create an issue about both a and b but not in this one.

Shall we change the CPPLINT rule?

@nodejs nodejs deleted a comment from nodejs-github-bot Apr 29, 2021
@nodejs nodejs deleted a comment from nodejs-github-bot Apr 29, 2021
@nodejs nodejs deleted a comment from nodejs-github-bot Apr 29, 2021
@nodejs nodejs deleted a comment from nodejs-github-bot Apr 29, 2021
@nodejs-github-bot
Copy link
Collaborator

@XadillaX XadillaX requested review from Qard and addaleax May 1, 2021 15:52
@nodejs-github-bot
Copy link
Collaborator

XadillaX added a commit that referenced this pull request Jun 1, 2021
@XadillaX
Copy link
Contributor Author

XadillaX commented Jun 1, 2021

Landed in f52dc17

@XadillaX XadillaX closed this Jun 1, 2021
danielleadams pushed a commit that referenced this pull request Jun 2, 2021
@danielleadams danielleadams mentioned this pull request Jun 2, 2021
@richardlau
Copy link
Member

This doesn't land cleanly on v14.x-staging.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c++ Issues and PRs that require attention from people who are familiar with C++. lib / src Issues and PRs related to general changes in the lib or src directory. needs-ci PRs that need a full CI run.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants