Pass RuntimeSchedulerCallInvoker to C++ TurboModule initialization

[rozele]

Description

Type of Change

Erase all that don't apply.

• Bug fix (non-breaking change which fixes an issue)

Why

Rather than creating a CallInvoker that posts to the JSDispatcher, this passes the same CallInvoker used for core TurboModules to 3rd party TurboModules and dispatches actions using the RuntimeScheduler if enabled.

Changelog

Should this change be included in the release notes: no

Microsoft Reviewers: Open in CodeFlow

[acoates-ms]

This breaks our ABI. CallInvoker by itself is not ABI safe. The implementation internal to the MS.RN.dll accesses all kinds of non-abi methods. The implementation used in TurboModules is provided outside the DLL and is a separate implementation which only calls ABI safe methods that are exported from the dll.

[acoates-ms]

Since this breaks the ABI, I doubt we can take this change.

[rozele]

@acoates-ms Out of curiosity, what is your plan for passing the runtime to C++ TurboModules?

I expect core React Native modules to start using this runtime argument in CallInvoker to invoke emitDeviceEvent. For reference, this is the mobile React Native change that will expose the jsi::Runtime argument in CallInvoker: facebook/react-native#43375. I don't think you've sync'd past this change yet.

I suppose you'll have to put the JsiRuntimeHolder somewhere accessible to the TurboModuleProvider, and pull the runtime off the JsiRuntimeHolder.

For non-ABI JSI use cases like we have in our apps at Meta, perhaps we could fallback on the RuntimeSchedulerCallInvoker (if the JsiRuntimeHolder is null or whatever)?

[jonthysell]

@acoates-ms Any update on this? Can we just close it?