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

Initialize the RuntimeScheduler and TurboModule bindings via RuntimeExecutor #12402

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
{
"type": "prerelease",
"comment": "Initialize the RuntimeScheduler and TurboModule bindings via RuntimeExecutor",
"packageName": "react-native-windows",
"email": "[email protected]",
"dependentChangeType": "patch"
}
23 changes: 9 additions & 14 deletions vnext/Shared/OInstance.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -361,17 +361,15 @@ InstanceImpl::InstanceImpl(
winrt::Microsoft::ReactNative::ReactPropertyBag(propertyBag), m_runtimeScheduler);
}

// Using runOnQueueSync because initializeBridge calls createJSExecutor with runOnQueueSync,
// so this is an attempt to keep the same semantics for exiting this method with TurboModuleManager
// initialized.
m_jsThread->runOnQueueSync([propertyBag,
innerInstance = m_innerInstance,
runtimeHolder = m_devSettings->jsiRuntimeHolder,
runtimeScheduler = m_runtimeScheduler,
turboModuleRegistry = m_turboModuleRegistry,
longLivedObjectCollection = m_longLivedObjectCollection]() {
// Use RuntimeExecutor so non-ABI JSExecutorFactory instances passed in through DevSettings
// can use the same logic
runtimeExecutor([propertyBag,
Copy link
Member

@vmoroz vmoroz Dec 2, 2023

Choose a reason for hiding this comment

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

Previously we ran this code synchronously.
As comment used to say that it enabled us to have the TurboModuleManager fully initialized by the time we exit the method.
This PR changes it to run asynchronously in a different thread. Thus, the TurboModuleManager maybe not initialized by the time we exit this method.
My concern is that this code may affect scenarios where we previously relied on the TurboModuleManager be initialized.

Should we run the runtimeExecutor synchronously here?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This deadlocks when trying to run synchronously on the RuntimeExecutor, so I left it as async for now.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I think perhaps we should do this conditionally. We can keep this "as is" if using ABI JSI, and switch to the async RuntimeExecutor only if using the non-ABI JSI option.

innerInstance = m_innerInstance,
runtimeScheduler = m_runtimeScheduler,
turboModuleRegistry = m_turboModuleRegistry,
longLivedObjectCollection = m_longLivedObjectCollection](jsi::Runtime &runtime) {
if (runtimeScheduler) {
RuntimeSchedulerBinding::createAndInstallIfNeeded(*runtimeHolder->getRuntime(), runtimeScheduler);
RuntimeSchedulerBinding::createAndInstallIfNeeded(runtime, runtimeScheduler);
}
auto turboModuleManager = std::make_shared<TurboModuleManager>(
turboModuleRegistry,
Expand All @@ -386,10 +384,7 @@ InstanceImpl::InstanceImpl(
};

TurboModuleBinding::install(
*runtimeHolder->getRuntime(),
std::function(binding),
TurboModuleBindingMode::HostObject,
longLivedObjectCollection);
runtime, std::function(binding), TurboModuleBindingMode::HostObject, longLivedObjectCollection);

// init TurboModule
for (const auto &moduleName : turboModuleManager->getEagerInitModuleNames()) {
Expand Down