introduce native api to access RuntimeExecutor #42882

philIip · 2024-02-06T08:06:27Z

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

This is the android equivalent of PR#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, i created an async api that will guarantee the runtime executor will be ready.

Differential Revision: D53461821

facebook-github-bot · 2024-02-06T08:06:37Z

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

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, i created an async api that will guarantee the runtime executor will be ready. Differential Revision: D53461821

facebook-github-bot · 2024-02-06T08:13:21Z

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

analysis-bot · 2024-02-06T08:41:44Z

Platform	Engine	Arch	Size (bytes)	Diff
android	hermes	arm64-v8a	17,233,692	-7
android	hermes	armeabi-v7a	n/a	--
android	hermes	x86	n/a	--
android	hermes	x86_64	n/a	--
android	jsc	arm64-v8a	20,600,119	-1
android	jsc	armeabi-v7a	n/a	--
android	jsc	x86	n/a	--
android	jsc	x86_64	n/a	--

Base commit: e37da1e
Branch: main

lukmccall · 2024-02-06T10:26:38Z

.../react-native/ReactAndroid/src/main/java/com/facebook/react/modules/fresco/FrescoModule.java

+
+    reactContext.executeRuntimeExecutor(
+        new ReactContext.ReactRuntimeExecutor() {
+          @Override
+          public void execute(RuntimeExecutor runtimeExecutor) {
+            // do something
+          }
+        });
+


Suggested change

reactContext.executeRuntimeExecutor(

new ReactContext.ReactRuntimeExecutor() {

@Override

public void execute(RuntimeExecutor runtimeExecutor) {

// do something

}

});

It doesn't do anything 🤷

oh whoops this was my testing code hehe

We should use a different module for this test.

At meta: FrescoModule is eagerly initialized when the ReactInstance is created.

So when this initialize method is executed, the ReactContext and the ReactHost don't have access to the ReactInstance reference (and hence the runtime executor reference), because it's being created.

That's probably why you had to create an async api to access the RuntimeExecutor?

lukmccall · 2024-02-06T10:26:43Z

packages/react-native/ReactAndroid/src/main/java/com/facebook/react/runtime/ReactHostImpl.java

+  void executeRuntimeExecutor(ReactRuntimeExecutor reactRuntimeExecutor) {
+    mReactInstanceTaskRef
+        .get()
+        .onSuccess(
+            task -> {
+              final ReactInstance reactInstance = task.getResult();
+              if (reactInstance == null) {
+                return false;
+              }
+              reactRuntimeExecutor.execute(reactInstance.getBufferedRuntimeExecutor());
+              return true;
+            },
+            mBGExecutor);
+  }


Access to the runtime executer will be obtained asynchronously. Currently, in our flow, module initialization starts when native constants are received. It is uncertain whether this will be invoked in time before the JS continues executing.

@lukmccall, the code is very different now.

NativeModules can now access the runtime by calling ReactContext.getRuntimeExecutor().

This method should work for all cases except for this one: when ReactHost's ReactInstance is/becomes null.

This happens in two scenarios:

The native module is created eagerly (i.e: while ReactHost is creating the ReactInstance).

The native module outlives the ReactInstance (i.e: ReactHost kills the ReactInstance, but something else keeps the native module alive).

Aside from that, I think the concern you mentioned about timing still exists.

I talked with Phillip offline: Maybe we could continue with this solution for now, and iterate on it, if we see any problems? I think we want to replace this solution with something more reliable down the line anyway.

RSNara · 2024-02-07T15:44:11Z

packages/react-native/ReactAndroid/src/main/java/com/facebook/react/runtime/ReactHostImpl.java

+  void executeRuntimeExecutor(ReactRuntimeExecutor reactRuntimeExecutor) {
+    mReactInstanceTaskRef
+        .get()
+        .onSuccess(
+            task -> {
+              final ReactInstance reactInstance = task.getResult();
+              if (reactInstance == null) {
+                return false;
+              }
+              reactRuntimeExecutor.execute(reactInstance.getBufferedRuntimeExecutor());
+              return true;
+            },
+            mBGExecutor);
+  }
+
+  /* package */
+  @Nullable


Suggested change

void executeRuntimeExecutor(ReactRuntimeExecutor reactRuntimeExecutor) {

mReactInstanceTaskRef

.get()

.onSuccess(

task -> {

final ReactInstance reactInstance = task.getResult();

if (reactInstance == null) {

return false;

}

reactRuntimeExecutor.execute(reactInstance.getBufferedRuntimeExecutor());

return true;

},

mBGExecutor);

}

/* package */

@Nullable

@Deprecated

RuntimeExecutor getRuntimeExecutor() {

return mReactInstanceTaskRef.get().getResult().getBufferedRuntimeExecutor();

}

/* package */

@Nullable

RSNara · 2024-02-07T15:45:21Z

...act-native/ReactAndroid/src/main/java/com/facebook/react/runtime/BridgelessReactContext.java

+  @Override
+  public void executeRuntimeExecutor(ReactRuntimeExecutor runtimeExecutor) {
+    mReactHost.executeRuntimeExecutor(runtimeExecutor);
+  }
+


Suggested change

@Override

public void executeRuntimeExecutor(ReactRuntimeExecutor runtimeExecutor) {

mReactHost.executeRuntimeExecutor(runtimeExecutor);

}

@Override

public RuntimeExecutor getRuntimeExecutor() {

return mReactHost.getRuntimeExecutor();

}

yea this was my first version but i ran into the issue with FrescoModule T_T but what you're saying for needsEagerInit for the FrescoModule makes sense

RSNara · 2024-02-07T17:25:28Z

.../react-native/ReactAndroid/src/main/java/com/facebook/react/modules/fresco/FrescoModule.java

+
+    reactContext.executeRuntimeExecutor(
+        new ReactContext.ReactRuntimeExecutor() {
+          @Override
+          public void execute(RuntimeExecutor runtimeExecutor) {
+            // do something
+          }
+        });
+


We should use a different module for this test.

At meta: FrescoModule is eagerly initialized when the ReactInstance is created.

So when this initialize method is executed, the ReactContext and the ReactHost don't have access to the ReactInstance reference (and hence the runtime executor reference), because it's being created.

That's probably why you had to create an async api to access the RuntimeExecutor?

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, i created an async api that will guarantee the runtime executor will be ready. Differential Revision: D53461821

facebook-github-bot · 2024-02-07T23:40:12Z

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

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

facebook-github-bot · 2024-02-07T23:41:36Z

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

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

facebook-github-bot · 2024-02-08T03:52:19Z

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

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

facebook-github-bot · 2024-02-08T03:52:52Z

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

facebook-github-bot · 2024-02-09T02:18:36Z

This pull request has been merged in d7dce97.

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 Feb 6, 2024

facebook-github-bot added fb-exported p: Facebook Partner: Facebook Partner labels Feb 6, 2024

philIip force-pushed the export-D53461821 branch from d29b833 to bb2ee82 Compare February 6, 2024 08:13

lukmccall reviewed Feb 6, 2024

View reviewed changes

RSNara reviewed Feb 7, 2024

View reviewed changes

philIip force-pushed the export-D53461821 branch from bb2ee82 to 27c3fe2 Compare February 7, 2024 23:39

philIip force-pushed the export-D53461821 branch from 27c3fe2 to bf10b63 Compare February 7, 2024 23:41

philIip force-pushed the export-D53461821 branch from bf10b63 to cf3ea88 Compare February 8, 2024 03:52

philIip force-pushed the export-D53461821 branch from cf3ea88 to ff47c1b Compare February 8, 2024 03:52

facebook-github-bot closed this in d7dce97 Feb 9, 2024

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

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

introduce native api to access RuntimeExecutor #42882

introduce native api to access RuntimeExecutor #42882

philIip commented Feb 6, 2024

facebook-github-bot commented Feb 6, 2024

facebook-github-bot commented Feb 6, 2024

analysis-bot commented Feb 6, 2024 •

edited

Loading

lukmccall Feb 6, 2024

philIip Feb 6, 2024

RSNara Feb 7, 2024

lukmccall Feb 6, 2024

RSNara Feb 8, 2024 •

edited

Loading

RSNara Feb 7, 2024

RSNara Feb 7, 2024

philIip Feb 7, 2024 •

edited

Loading

RSNara Feb 7, 2024

facebook-github-bot commented Feb 7, 2024

facebook-github-bot commented Feb 7, 2024

facebook-github-bot commented Feb 8, 2024

facebook-github-bot commented Feb 8, 2024

facebook-github-bot commented Feb 9, 2024

introduce native api to access RuntimeExecutor #42882

introduce native api to access RuntimeExecutor #42882

Conversation

philIip commented Feb 6, 2024

facebook-github-bot commented Feb 6, 2024

facebook-github-bot commented Feb 6, 2024

analysis-bot commented Feb 6, 2024 • edited Loading

lukmccall Feb 6, 2024

Choose a reason for hiding this comment

philIip Feb 6, 2024

Choose a reason for hiding this comment

RSNara Feb 7, 2024

Choose a reason for hiding this comment

lukmccall Feb 6, 2024

Choose a reason for hiding this comment

RSNara Feb 8, 2024 • edited Loading

Choose a reason for hiding this comment

RSNara Feb 7, 2024

Choose a reason for hiding this comment

RSNara Feb 7, 2024

Choose a reason for hiding this comment

philIip Feb 7, 2024 • edited Loading

Choose a reason for hiding this comment

RSNara Feb 7, 2024

Choose a reason for hiding this comment

facebook-github-bot commented Feb 7, 2024

facebook-github-bot commented Feb 7, 2024

facebook-github-bot commented Feb 8, 2024

facebook-github-bot commented Feb 8, 2024

facebook-github-bot commented Feb 9, 2024

analysis-bot commented Feb 6, 2024 •

edited

Loading

RSNara Feb 8, 2024 •

edited

Loading

philIip Feb 7, 2024 •

edited

Loading