Commit Graph

2 Commits

Author SHA1 Message Date
Ramanpreet Nara 32bfd7a857 Stop sharing LongLivedObjectCollection with the bridge
Summary:
## Context
Previously, when you'd call TurboModule methods with JavaScript callbacks, we'd [store the callbacks](https://www.internalfb.com/code/fbsource/[c503ff1b38621aebca87b2bbebeae088b01886c4]/xplat/js/react-native-github/ReactCommon/react/nativemodule/core/platform/ios/RCTTurboModule.mm?lines=173%2C248-249) into [this global LongLivedObjectCollection collection](https://www.internalfb.com/code/fbsource/[c503ff1b38621aebca87b2bbebeae088b01886c4]/xplat/js/react-native-github/ReactCommon/react/nativemodule/core/ReactCommon/TurboModuleUtils.h?lines=65). Then, when React Native's JavaScript VM got torn down, we'd [clear the global collection](https://www.internalfb.com/code/fbsource/[e26f476ce208c578f05b1edb7639d1dad5612c7d]/xplat/js/react-native-github/ReactCommon/react/nativemodule/core/ReactCommon/TurboModuleBinding.cpp?lines=49), which would ensure that we deleted all held jsi::Functions, before deleting the jsi::Runtime.

## Problem
With bridgeless mode enabled, there can be two TurboModule systems. Further, it is possible to tear down bridgeless mode, or the bridge, without tearing down the other initialization infra. In this scenario, the jsi::Function for the other initialization infra would also get deleted, which could lead to mysterious problems.

## Fix
In this diff, I refactored the jsi::Function cleanup in the TurboModule system. Now, there are 3 modes:
- kGlobalScope: Everything works as it did before
- kRCTGlobalScopeUsingRetainJSCallback: We still use the global LongLivedObjectCollection, but we do it through invoking a block passed to every ObjCTurboModule by the TurboModuleManager. This group exists to assess the impact of having each TurboModule retain/use the block. I suspect this will be negligible, but it'd be good to have actual data to back this claim.
- kRCTTurboModuleManagerScope: Every TurboModule uses a LongLivedObjectCollection that is owned by its TurboModuleManager. This should effectively fix the problem I outlined above.

Changelog: [Internal]

Reviewed By: p-sun

Differential Revision: D30019833

fbshipit-source-id: da50d884c7e37190107f570d8ed70eeda7d9ae83
2021-08-02 11:22:22 -07:00
Kevin Gozali 5be44456f2 TurboModule Android: compile TurboModule C++ Core into ReactAndroid
Summary:
This is to prepare for enabling TurboModule on Android. This commit compiles in all the core files (C++) into the ReactAndroid NDK build step. This doesn't yet enable TurboModule by default, just compiling in the infra, just like for iOS.

New shared libs:
* libreact_nativemodule_core.so: The TurboModule Android core
* libreact_nativemodule_manager.so: The TurboModule manager/delegate

To be compatible with `<ReactCommon/` .h include prefix, the files had to move to local `ReactCommon` subdirs.

Changelog: [Internal]

Reviewed By: sammy-SC

Differential Revision: D23805717

fbshipit-source-id: b41c392a592dd095ae003f7b2a689f4add2c37a9
2020-09-20 14:23:43 -07:00