introduce native api to access RuntimeExecutor by philIip · Pull Request #42758 · facebook/react-native

philIip · 2024-01-31T07:43:00Z

Summary:
Changelog: [Added][iOS] introduce native api to access RuntimeExecutor

The goal of this API is to provide a safe way to access the jsi::runtime in bridgeless mode. The decision to limit access to the runtime in bridgeless was a conscious one - the runtime pointer is not thread-safe and its lifecycle must be managed correctly by owners.

However, interacting with the runtime is an advanced use case we would want to support. Our recommended ways to access the runtime in bridgeless mode is either 1) via the RuntimeExecutor, or 2) via a C++ TurboModule.

This diff introduces the API that would allow for 1). The integration consists of these parts:

Wrapper objects for RuntimeExecutor access. These are RCTRuntimeExecution and RCTRuntimeExecutionWrapper. RCTRuntimeExecutionWrapper is a C++ free wrapper of RCTRuntimeExecution to be reliably used in Swift modules.
The new API on RCTBridgeModule, following a similar pattern to other decoration APIs, and integration with our module infrastructure.

Differential Revision: D53256188

facebook-github-bot · 2024-01-31T07:43:10Z

This pull request was exported from Phabricator. Differential Revision: D53256188

tsapeta · 2024-01-31T14:04:16Z

packages/react-native/React/Base/RCTRuntimeExecutionWrapper.h

Do we need the wrapper class? It seems to be just wrapping RCTRuntimeExecution without the C++ stuff. I think hiding the C++ part with #ifdef __cplusplus in RCTRuntimeExecution makes more sense and doesn't need to introduce another class.

the main reason is that i didn't know how to correctly use that flag for swift interop so i just went with something i knew would work, lol

i also think an additional benefit of the wrapper class is that it allows you to use RCTRuntimeExecution without having to pull in the ReactCommon dependency, so ExpoBridgeModule doesn't have to bring in any new deps. RCTRuntimeExecutionWrapper has no dep on RCTRuntimeExecution which is nice when we just need to pass it around.

ok @tsapeta i got rid of the wrapper class!

if it's a swift module, it should only pull in the forward declarations from RCTRuntimeExecutionModule protocol, then pass it down to an obj-c++ file. then that file can import RCTRuntimeExecutorProvider.h, so there should be no need for compiler flag either!

tsapeta · 2024-01-31T15:18:06Z

...native/ReactCommon/react/nativemodule/core/platform/ios/ReactCommon/RCTTurboModuleManager.mm

👀

Suggested change

[(id)module setValue:runtimeExecutionWrapper forKey:@"runtimeExeuctionWrapper"];

[(id)module setValue:runtimeExecutionWrapper forKey:@"runtimeExecutionWrapper"];

i blame KVO

facebook-github-bot · 2024-01-31T19:45:00Z

This pull request was exported from Phabricator. Differential Revision: D53256188

analysis-bot · 2024-01-31T20:12:06Z

Platform	Engine	Arch	Size (bytes)	Diff
android	hermes	arm64-v8a	17,233,416	-5
android	hermes	armeabi-v7a	n/a	--
android	hermes	x86	n/a	--
android	hermes	x86_64	n/a	--
android	jsc	arm64-v8a	20,600,227	+6
android	jsc	armeabi-v7a	n/a	--
android	jsc	x86	n/a	--
android	jsc	x86_64	n/a	--

Base commit: e4342f5
Branch: main

facebook-github-bot · 2024-01-31T23:34:46Z

This pull request was exported from Phabricator. Differential Revision: D53256188

facebook-github-bot · 2024-01-31T23:37:52Z

This pull request was exported from Phabricator. Differential Revision: D53256188

facebook-github-bot · 2024-02-01T00:37:30Z

This pull request was exported from Phabricator. Differential Revision: D53256188

facebook-github-bot · 2024-02-01T00:37:51Z

This pull request was exported from Phabricator. Differential Revision: D53256188

facebook-github-bot · 2024-02-01T00:51:18Z

This pull request was exported from Phabricator. Differential Revision: D53256188

facebook-github-bot · 2024-02-01T00:51:40Z

This pull request was exported from Phabricator. Differential Revision: D53256188

facebook-github-bot · 2024-02-05T22:07:59Z

This pull request was exported from Phabricator. Differential Revision: D53256188

facebook-github-bot · 2024-02-05T22:26:49Z

This pull request was exported from Phabricator. Differential Revision: D53256188

facebook-github-bot · 2024-02-05T23:00:37Z

This pull request was exported from Phabricator. Differential Revision: D53256188

facebook-github-bot · 2024-02-05T23:46:16Z

This pull request was exported from Phabricator. Differential Revision: D53256188

Summary: Changelog: [iOS][Added] - introduce native api to access RuntimeExecutor The goal of this API is to provide a safe way to access the `jsi::runtime` in bridgeless mode. The decision to limit access to the runtime in bridgeless was a conscious one - the runtime pointer is not thread-safe and its lifecycle must be managed correctly by owners. However, interacting with the runtime is an advanced use case we would want to support. Our recommended ways to access the runtime in bridgeless mode is either 1) via the RuntimeExecutor, or 2) via a C++ TurboModule. This diff introduces the API that would allow for 1). The integration consists of these parts: - wrapper object for RuntimeExecutor access, `RCTRuntimeExecutor`. The NSObject wrapper is necessary so we can make it the property of a swift module - new protocol API,`RCTRuntimeExecutionModule`, for modules to access the RuntimeExecutor block - integration within the bridgeless infrastructure Reviewed By: javache Differential Revision: D53256188

facebook-github-bot · 2024-02-05T23:48:13Z

This pull request was exported from Phabricator. Differential Revision: D53256188

facebook-github-bot · 2024-02-05T23:49:38Z

This pull request was exported from Phabricator. Differential Revision: D53256188

facebook-github-bot · 2024-02-06T12:01:12Z

This pull request has been merged in 343a0d3.

Summary: Changelog: [Android][Added] - introduce native api to access RuntimeExecutor This is the android equivalent of [PR#42758](facebook#42758). From [PR#42758](facebook#42758) > The goal of this API is to provide a safe way to access the jsi::runtime in bridgeless mode. The decision to limit access to the runtime in bridgeless was a conscious one - the runtime pointer is not thread-safe and its lifecycle must be managed correctly by owners. > However, interacting with the runtime is an advanced use case we would want to support. Our recommended ways to access the runtime in bridgeless mode is either 1) via the RuntimeExecutor, or 2) via a C++ TurboModule. This diff introduces the API that would allow for 1). because react context can be non-null before react instance is ready, this can still return null. however, the callsite should be cognizant of when this will happen. in the case of expomodules, the runtime should be ready when the module is init, unless it is a eager initialized module Differential Revision: D53461821

Summary: Pull Request resolved: #42882 Changelog: [Android][Added] - introduce native api to access RuntimeExecutor This is the android equivalent of [PR#42758](#42758). From [PR#42758](#42758) > The goal of this API is to provide a safe way to access the jsi::runtime in bridgeless mode. The decision to limit access to the runtime in bridgeless was a conscious one - the runtime pointer is not thread-safe and its lifecycle must be managed correctly by owners. > However, interacting with the runtime is an advanced use case we would want to support. Our recommended ways to access the runtime in bridgeless mode is either 1) via the RuntimeExecutor, or 2) via a C++ TurboModule. This diff introduces the API that would allow for 1). because react context can be non-null before react instance is ready, this can still return null. however, the callsite should be cognizant of when this will happen. in the case of expomodules, the runtime should be ready when the module is init, unless it is a eager initialized module Reviewed By: RSNara Differential Revision: D53461821 fbshipit-source-id: 69555d0593a59f8655e4dcd2f0ef1f78f4cfff7d

facebook-github-bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Jan 31, 2024

facebook-github-bot added fb-exported p: Facebook Partner: Facebook Partner labels Jan 31, 2024

tsapeta reviewed Jan 31, 2024

View reviewed changes

philIip force-pushed the export-D53256188 branch from c764a85 to 725f698 Compare January 31, 2024 19:44

philIip force-pushed the export-D53256188 branch from 725f698 to 9b3709e Compare January 31, 2024 23:34

philIip force-pushed the export-D53256188 branch from 9b3709e to 63959e7 Compare January 31, 2024 23:37

philIip force-pushed the export-D53256188 branch from 63959e7 to 9ec157b Compare February 1, 2024 00:37

philIip force-pushed the export-D53256188 branch from 9ec157b to 3f2e95d Compare February 1, 2024 00:37

philIip force-pushed the export-D53256188 branch from 3f2e95d to 874a931 Compare February 1, 2024 00:51

philIip force-pushed the export-D53256188 branch from 874a931 to c328238 Compare February 1, 2024 00:51

philIip force-pushed the export-D53256188 branch from c328238 to 9ca18c1 Compare February 1, 2024 00:53

philIip force-pushed the export-D53256188 branch from 937e1f8 to 8566e31 Compare February 5, 2024 22:07

philIip force-pushed the export-D53256188 branch from 8566e31 to beafed8 Compare February 5, 2024 22:26

philIip force-pushed the export-D53256188 branch from beafed8 to fea6af5 Compare February 5, 2024 23:00

philIip force-pushed the export-D53256188 branch from fea6af5 to f7b4a76 Compare February 5, 2024 23:46

philIip force-pushed the export-D53256188 branch from f7b4a76 to 67b9036 Compare February 5, 2024 23:47

philIip force-pushed the export-D53256188 branch from 67b9036 to e43e857 Compare February 5, 2024 23:49

philIip mentioned this pull request Feb 6, 2024

introduce native api to access RuntimeExecutor #42882

Closed

facebook-github-bot closed this in 343a0d3 Feb 6, 2024

facebook-github-bot added the Merged This PR has been merged. label Feb 6, 2024

	[(id)module setValue:runtimeExecutionWrapper forKey:@"runtimeExeuctionWrapper"];
	[(id)module setValue:runtimeExecutionWrapper forKey:@"runtimeExecutionWrapper"];

Conversation

philIip commented Jan 31, 2024

Uh oh!

facebook-github-bot commented Jan 31, 2024

Uh oh!

tsapeta Jan 31, 2024

Choose a reason for hiding this comment

Uh oh!

philIip Jan 31, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

philIip Feb 1, 2024

Choose a reason for hiding this comment

Uh oh!

tsapeta Jan 31, 2024

Choose a reason for hiding this comment

Uh oh!

philIip Jan 31, 2024

Choose a reason for hiding this comment

Uh oh!

facebook-github-bot commented Jan 31, 2024

Uh oh!

analysis-bot commented Jan 31, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

facebook-github-bot commented Jan 31, 2024

Uh oh!

facebook-github-bot commented Jan 31, 2024

Uh oh!

facebook-github-bot commented Feb 1, 2024

Uh oh!

facebook-github-bot commented Feb 1, 2024

Uh oh!

facebook-github-bot commented Feb 1, 2024

Uh oh!

facebook-github-bot commented Feb 1, 2024

Uh oh!

facebook-github-bot commented Feb 5, 2024

Uh oh!

facebook-github-bot commented Feb 5, 2024

Uh oh!

facebook-github-bot commented Feb 5, 2024

Uh oh!

facebook-github-bot commented Feb 5, 2024

Uh oh!

facebook-github-bot commented Feb 5, 2024

Uh oh!

facebook-github-bot commented Feb 5, 2024

Uh oh!

facebook-github-bot commented Feb 6, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

philIip Jan 31, 2024 •

edited

Loading

analysis-bot commented Jan 31, 2024 •

edited

Loading