introduce native api to access RuntimeExecutor #42758
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
facebook-github-bot
added
the
CLA Signed
|
This pull request was exported from Phabricator. Differential Revision: D53256188 |
tsapeta
reviewed
Jan 31, 2024
| /** | ||
| Swift friendly wrapper of RCTRuntimeExecution. | ||
| */ | ||
| @interface RCTRuntimeExecutionWrapper : NSObject |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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!
| }]; | ||
| RCTRuntimeExecutionWrapper *runtimeExecutionWrapper = | ||
| [[RCTRuntimeExecutionWrapper alloc] initWithRuntimeExecution:runtimeExecution]; | ||
| [(id)module setValue:runtimeExecutionWrapper forKey:@"runtimeExeuctionWrapper"]; |
There was a problem hiding this comment.
👀
Suggested change
| [(id)module setValue:runtimeExecutionWrapper forKey:@"runtimeExeuctionWrapper"]; | |
| [(id)module setValue:runtimeExecutionWrapper forKey:@"runtimeExecutionWrapper"]; |
philIip
added a commit
to philIip/react-native
that referenced
this pull request
Jan 31, 2024
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
philIip
force-pushed
the
export-D53256188
branch
from
c764a85 to
725f698
Compare
|
This pull request was exported from Phabricator. Differential Revision: D53256188 |
Base commit: e4342f5 |
philIip
added a commit
to philIip/react-native
that referenced
this pull request
Jan 31, 2024
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
philIip
force-pushed
the
export-D53256188
branch
from
725f698 to
9b3709e
Compare
|
This pull request was exported from Phabricator. Differential Revision: D53256188 |
philIip
added a commit
to philIip/react-native
that referenced
this pull request
Jan 31, 2024
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
philIip
force-pushed
the
export-D53256188
branch
from
9b3709e to
63959e7
Compare
|
This pull request was exported from Phabricator. Differential Revision: D53256188 |
philIip
added a commit
to philIip/react-native
that referenced
this pull request
Feb 1, 2024
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
philIip
force-pushed
the
export-D53256188
branch
from
63959e7 to
9ec157b
Compare
|
This pull request was exported from Phabricator. Differential Revision: D53256188 |
philIip
added a commit
to philIip/react-native
that referenced
this pull request
Feb 1, 2024
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
philIip
force-pushed
the
export-D53256188
branch
from
9ec157b to
3f2e95d
Compare
|
This pull request was exported from Phabricator. Differential Revision: D53256188 |
philIip
force-pushed
the
export-D53256188
branch
from
3f2e95d to
874a931
Compare
philIip
added a commit
to philIip/react-native
that referenced
this pull request
Feb 1, 2024
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
|
This pull request was exported from Phabricator. Differential Revision: D53256188 |
philIip
added a commit
to philIip/react-native
that referenced
this pull request
Feb 1, 2024
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
philIip
force-pushed
the
export-D53256188
branch
from
874a931 to
c328238
Compare
|
This pull request was exported from Phabricator. Differential Revision: D53256188 |
philIip
added a commit
to philIip/react-native
that referenced
this pull request
Feb 1, 2024
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
philIip
force-pushed
the
export-D53256188
branch
from
c328238 to
9ca18c1
Compare
philIip
force-pushed
the
export-D53256188
branch
from
937e1f8 to
8566e31
Compare
philIip
added a commit
to philIip/react-native
that referenced
this pull request
Feb 5, 2024
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
|
This pull request was exported from Phabricator. Differential Revision: D53256188 |
philIip
added a commit
to philIip/react-native
that referenced
this pull request
Feb 5, 2024
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
philIip
force-pushed
the
export-D53256188
branch
from
8566e31 to
beafed8
Compare
|
This pull request was exported from Phabricator. Differential Revision: D53256188 |
philIip
added a commit
to philIip/react-native
that referenced
this pull request
Feb 5, 2024
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
philIip
force-pushed
the
export-D53256188
branch
from
beafed8 to
fea6af5
Compare
|
This pull request was exported from Phabricator. Differential Revision: D53256188 |
philIip
added a commit
to philIip/react-native
that referenced
this pull request
Feb 5, 2024
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
philIip
force-pushed
the
export-D53256188
branch
from
fea6af5 to
f7b4a76
Compare
|
This pull request was exported from Phabricator. Differential Revision: D53256188 |
philIip
added a commit
to philIip/react-native
that referenced
this pull request
Feb 5, 2024
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
philIip
force-pushed
the
export-D53256188
branch
from
f7b4a76 to
67b9036
Compare
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
|
This pull request was exported from Phabricator. Differential Revision: D53256188 |
philIip
force-pushed
the
export-D53256188
branch
from
67b9036 to
e43e857
Compare
|
This pull request was exported from Phabricator. Differential Revision: D53256188 |
philIip
added a commit
to philIip/react-native
that referenced
this pull request
Feb 6, 2024
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
philIip
added a commit
to philIip/react-native
that referenced
this pull request
Feb 6, 2024
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
|
This pull request has been merged in 343a0d3. |
philIip
added a commit
to philIip/react-native
that referenced
this pull request
Feb 7, 2024
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
philIip
added a commit
to philIip/react-native
that referenced
this pull request
Feb 7, 2024
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
philIip
added a commit
to philIip/react-native
that referenced
this pull request
Feb 8, 2024
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
philIip
added a commit
to philIip/react-native
that referenced
this pull request
Feb 8, 2024
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
pushed a commit
that referenced
this pull request
Feb 9, 2024
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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::runtimein 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:
RCTRuntimeExecutionandRCTRuntimeExecutionWrapper. RCTRuntimeExecutionWrapper is a C++ free wrapper of RCTRuntimeExecution to be reliably used in Swift modules.Differential Revision: D53256188