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

Fix: Detect Electron version at runtime #546

Merged
merged 4 commits into from Dec 7, 2022

Conversation

Bartel-C8
Copy link
Contributor

This way, no separate build for NodeJS and Electron v21(+) is needed.
Cache the result once, to not have to look up the value on each incoming message.

does include an overhead in having to call a finalizer when the
buffer is GC'ed. For very small messages it is faster to copy. */
moved = true;
if (!hasElectronMemoryCage(env)) {
Copy link
Member

@aminya aminya Dec 6, 2022

Choose a reason for hiding this comment

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

Suggested change
if (!hasElectronMemoryCage(env)) {
if (noElectronMemoryCage) {


namespace zmq {
bool hasRun = false;
bool hasElectronMemoryCageCache = false;
Copy link
Member

Choose a reason for hiding this comment

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

I think using the static keyword in the call site should be enough. Extra caching is not probably needed.

again in any case. This should not happen of course. */
ErrnoException(env, EINVAL).ThrowAsJavaScriptException();
return env.Undefined();
if (!hasElectronMemoryCage(env)) {
Copy link
Member

Choose a reason for hiding this comment

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

It might be faster to make this variable static so that it is calculated only once.

Suggested change
if (!hasElectronMemoryCage(env)) {
static const auto noElectronMemoryCage = !hasElectronMemoryCage(env);
if (noElectronMemoryCage) {

Copy link
Contributor Author

@Bartel-C8 Bartel-C8 Dec 6, 2022

Choose a reason for hiding this comment

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

I am actually not sure, because, how I understand it, the class/function is being constructed and destroyed for each incoming message. So for each message then the function is called and re-evaluated.

That's why I opted for caching in the function one level up...

What's your thought about this?

Copy link
Member

@aminya aminya Dec 6, 2022

Choose a reason for hiding this comment

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

Yeah, it makes sense to reuse the cache for all the messages. What about making the result of the check a static property of IncomingMsg?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, good idea! I can make the changes on Thursday morning!

Copy link
Member

Choose a reason for hiding this comment

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

It can be a separate PR. This should work for now.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think I have it, testing as we speak. Will commit in this branch.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Wasn't able to make it a class member (at this moment), as I need the passed on env, which is only passed in the IntoBuffer function. At least one function call is reduced.

This way, no separate build for NodeJS and Electron v21(+) is needed.
Cache the result once, to not have to look up the value on each incoming message.
@aminya aminya merged commit f750205 into zeromq:master Dec 7, 2022
@Bartel-C8 Bartel-C8 deleted the runtimeElectronCheck branch December 8, 2022 12:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants