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 Node-API calling conventions #122

Merged
2 commits merged into from
Apr 19, 2022

Conversation

vmoroz
Copy link
Member

@vmoroz vmoroz commented Apr 18, 2022

The issue

When we tried to adopt the Node-API based code in ReactNative for Windows we have got runtime crashes in x86 Release mode.

The issue is that some function pointers in Node-API did not have explicit calling conventions and since react-native-win32.dll produced by ReactNative for Windows uses __stdcall calling conventions by default while most of Node-API is __cdecl, we have got a mismatch in calling conventions for all function pointers passed to Node-API. The Node-API is expecting __cdecl function pointer and given a __stdcall function pointer instead. It causes a runtime crash.

The solution

We set the __cdecl explicitly for function pointers in js_native_api_types.h and js_native_ext_api.h.
The NapiJsiRuntime implementation is updated to use explicit __cdecl decorator for the Node-API function pointers.

Microsoft Reviewers: Open in CodeFlow

@tudorms
Copy link
Member

tudorms commented Apr 18, 2022

It was nice to have NodeApiJsiRuntime.h/.cpp alongside the napi implementation; we could test it at the source, and make the package consumable stand-alone (without RNW). But if we add napi+jsi tests in RNW that should provide some coverage as well.

Copy link
Member

@tudorms tudorms left a comment

Choose a reason for hiding this comment

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

:shipit:

@@ -28,13 +28,13 @@ typedef struct napi_ext_env_scope__ *napi_ext_env_scope;
typedef struct napi_ext_ref__ *napi_ext_ref;

// A callback to return buffer synchronously
typedef void (*napi_ext_buffer_callback)(napi_env env, uint8_t const *buffer, size_t buffer_length, void *buffer_hint);
typedef void (__cdecl *napi_ext_buffer_callback)(napi_env env, uint8_t const *buffer, size_t buffer_length, void *buffer_hint);
Copy link
Contributor

Choose a reason for hiding this comment

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

__cdecl

Can we add some tests that verify that we don't lose this signature over time?

Copy link
Member Author

Choose a reason for hiding this comment

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

I cannot think about any such test. Any ideas?

@vmoroz
Copy link
Member Author

vmoroz commented Apr 18, 2022

It was nice to have NodeApiJsiRuntime.h/.cpp alongside the napi implementation; we could test it at the source, and make the package consumable stand-alone (without RNW). But if we add napi+jsi tests in RNW that should provide some coverage as well.

I see your point and it was not an easy decision. Currently we have three copies of this code: here, hermes-windows, and RNW. I want to have a single copy instead. Having a full repo just for these few lines seems to be too much. My current thoughts to have all this code inside of RNW, but like you said it makes it difficult to use v8jsi.dll package on its own.
I am open to other ideas.

@vmoroz
Copy link
Member Author

vmoroz commented Apr 19, 2022

It was nice to have NodeApiJsiRuntime.h/.cpp alongside the napi implementation; we could test it at the source, and make the package consumable stand-alone (without RNW). But if we add napi+jsi tests in RNW that should provide some coverage as well.

I see your point and it was not an easy decision. Currently we have three copies of this code: here, hermes-windows, and RNW. I want to have a single copy instead. Having a full repo just for these few lines seems to be too much. My current thoughts to have all this code inside of RNW, but like you said it makes it difficult to use v8jsi.dll package on its own. I am open to other ideas.

I am going to restore the JSI for Node-API implementation before merging this PR.
We should discuss offline what should be our strategy about the APIs consisting of a couple of files and shared across multiple repos.

@ghost
Copy link

ghost commented Apr 19, 2022

Hello @vmoroz!

Because this pull request has the auto merge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

@ghost ghost merged commit d514fe5 into microsoft:master Apr 19, 2022
vmoroz added a commit that referenced this pull request Apr 19, 2022
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants