src: cache necessary isolate & context in api/*

[XadillaX]

Refs: #37473

[joyeecheung]

LGTM with a nit

[joyeecheung]

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

[XadillaX]

• bca23f2
• f27b5e4#diff-6c1386cbc6e4a11941649af31a0257d5c3e40b5f41223cdddf87ab2e984b705aR1396

/cc @addaleax

[addaleax]

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

[addaleax]

@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

[addaleax]

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]

@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]

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]

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-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/37793/

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/38411/

[XadillaX]

Landed in f52dc17

[richardlau]

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