Make RNM work with use_frameworks #2
Draft
Conversation
This file contains hidden or 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
Include timestamp in nightly versions
* Respect system proxy settings for WebSocket * Update yarn.lock * Update Podfile.lock --------- Co-authored-by: Adam Gleitman <[email protected]>
* Respect system proxy settings for WebSocket * Update yarn.lock * Update Podfile.lock * Add macOS tags * Revert "Update yarn.lock" This reverts commit 91c448e. * Revert "Update Podfile.lock" This reverts commit f65b797. * nit: fix ending macOS tag Co-authored-by: Saad Najmi <[email protected]> --------- Co-authored-by: Adam Gleitman <[email protected]> Co-authored-by: Saad Najmi <[email protected]>
) * Don't passthru key events that override Pressibilty api's * Remove key callbacks instead of commenting out --------- Co-authored-by: Shawn Dempsey <[email protected]>
…1729) * Update yarn.lock via `yarn upgrade` * Update snapshots --------- Co-authored-by: Adam Gleitman <[email protected]>
…ebook#329)" This reverts commit a4287a0.
Co-authored-by: Shawn Dempsey <[email protected]>
…0.72 Pull in a few pipeline fixes from 0.72-stable
Merge up to September 20th
Merge up to 0.73 branch cut
cipolleschi
force-pushed
the
cipolleschi/macos-use_frameworks
branch
from
c5c99d2 to
52c075e
Compare
cipolleschi
pushed a commit
that referenced
this pull request
May 14, 2025
…tion for existing view (facebook#51294) Summary: Pull Request resolved: facebook#51294 changelog: [internal] Fix a crash where a node that is supposed to be culled doesn't get visited because culling context is not updated. The differentiator would generate a create instruction for a view that already exists. Stack trace for the crash: ``` * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT * frame #0: 0x0000000111740874 libsystem_kernel.dylib`__pthread_kill + 8 frame #1: 0x00000001117aa2ec libsystem_pthread.dylib`pthread_kill + 264 frame #2: 0x0000000180171ea8 libsystem_c.dylib`abort + 100 frame facebook#3: 0x00000001802b0144 libc++abi.dylib`abort_message + 128 frame facebook#4: 0x000000018029fe4c libc++abi.dylib`demangling_terminate_handler() + 296 frame facebook#5: 0x000000018006f220 libobjc.A.dylib`_objc_terminate() + 124 frame facebook#6: 0x00000001375d1964 INFRAFramework`meta_terminate() + 5468 frame facebook#7: 0x00000001802af570 libc++abi.dylib`std::__terminate(void (*)()) + 12 frame facebook#8: 0x00000001802b2498 libc++abi.dylib`__cxxabiv1::failed_throw(__cxxabiv1::__cxa_exception*) + 32 frame facebook#9: 0x00000001802b2478 libc++abi.dylib`__cxa_throw + 88 frame facebook#10: 0x0000000180093904 libobjc.A.dylib`objc_exception_throw + 384 frame facebook#11: 0x0000000180e6999c Foundation`-[NSAssertionHandler handleFailureInFunction:file:lineNumber:description:] + 268 frame facebook#12: 0x000000031a3bcfc8 XPLAT_6_Framework`-[RCTComponentViewRegistry dequeueComponentViewWithComponentHandle:tag:] + 528 frame facebook#13: 0x000000031a3ccdec XPLAT_6_Framework`RCTPerformMountInstructions(std::__1::vector<facebook::react::ShadowViewMutation, std::__1::allocator<facebook::react::ShadowViewMutation>> const&, RCTComponentViewRegistry*, RCTMountingTransactionObserverCoordinator&, int) + 356 frame facebook#14: 0x000000031a3ccc7c XPLAT_6_Framework`-[RCTMountingManager performTransaction:]::$_1::operator()(facebook::react::MountingTransaction const&, facebook::react::SurfaceTelemetry const&) const + 80 frame facebook#15: 0x000000031a3ccc20 XPLAT_6_Framework`decltype(std::declval<-[RCTMountingManager performTransaction:]::$_1&>()(std::declval<facebook::react::MountingTransaction const&>(), std::declval<facebook::react::SurfaceTelemetry const&>())) std::__1::__invoke[abi:ne190102]<-[RCTMountingManager performTransaction:]::$_1&, facebook::react::MountingTransaction const&, facebook::react::SurfaceTelemetry const&>(-[RCTMountingManager performTransaction:]::$_1&, facebook::react::MountingTransaction const&, facebook::react::SurfaceTelemetry const&) + 40 frame facebook#16: 0x000000031a3ccbc8 XPLAT_6_Framework`void std::__1::__invoke_void_return_wrapper<void, true>::__call[abi:ne190102]<-[RCTMountingManager performTransaction:]::$_1&, facebook::react::MountingTransaction const&, facebook::react::SurfaceTelemetry const&>(-[RCTMountingManager performTransaction:]::$_1&, facebook::react::MountingTransaction const&, facebook::react::SurfaceTelemetry const&) + 40 frame facebook#17: 0x000000031a3ccb94 XPLAT_6_Framework`std::__1::__function::__alloc_func<-[RCTMountingManager performTransaction:]::$_1, std::__1::allocator<-[RCTMountingManager performTransaction:]::$_1>, void (facebook::react::MountingTransaction const&, facebook::react::SurfaceTelemetry const&)>::operator()[abi:ne190102](facebook::react::MountingTransaction const&, facebook::react::SurfaceTelemetry const&) + 44 frame facebook#18: 0x000000031a3cba1c XPLAT_6_Framework`std::__1::__function::__func<-[RCTMountingManager performTransaction:]::$_1, std::__1::allocator<-[RCTMountingManager performTransaction:]::$_1>, void (facebook::react::MountingTransaction const&, facebook::react::SurfaceTelemetry const&)>::operator()(facebook::react::MountingTransaction const&, facebook::react::SurfaceTelemetry const&) + 44 frame facebook#20: 0x000000032f219804 XPLAT_1_Framework`std::__1::function<void (facebook::react::MountingTransaction const&, facebook::react::SurfaceTelemetry const&)>::operator()(this=0x000000016d4f0c78, __arg=0x000000016d4f0a10, __arg=0x000000016d4f0978) const at function.h:989:10 frame facebook#21: 0x000000032f219668 XPLAT_1_Framework`facebook::react::TelemetryController::pullTransaction(this=0x00000003f4680f00, willMount=0x000000016d4f0c98, doMount=0x000000016d4f0c78, didMount=0x000000016d4f0c58) const at TelemetryController.cpp:39:3 frame facebook#22: 0x000000031a3c5b28 XPLAT_6_Framework`-[RCTMountingManager performTransaction:] + 544 frame facebook#23: 0x000000031a3c5864 XPLAT_6_Framework`-[RCTMountingManager initiateTransaction:] + 456 frame facebook#24: 0x000000031a3c5240 XPLAT_6_Framework`__42-[RCTMountingManager scheduleTransaction:]_block_invoke + 308 frame facebook#25: 0x0000000131f81b84 BOTTOMFramework`__RCTExecuteOnMainQueue_block_invoke + 40 frame facebook#26: 0x000000018017c788 libdispatch.dylib`_dispatch_call_block_and_release + 24 frame facebook#27: 0x0000000180197278 libdispatch.dylib`_dispatch_client_callout + 12 frame facebook#28: 0x00000001801b2fcc libdispatch.dylib`_dispatch_main_queue_drain.cold.7 + 24 frame facebook#29: 0x000000018018c1c4 libdispatch.dylib`_dispatch_main_queue_drain + 1184 frame facebook#30: 0x000000018018bd14 libdispatch.dylib`_dispatch_main_queue_callback_4CF + 40 frame facebook#31: 0x0000000180427fec CoreFoundation`__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12 frame facebook#32: 0x00000001804229f8 CoreFoundation`__CFRunLoopRun + 1920 frame facebook#33: 0x0000000180421e3c CoreFoundation`CFRunLoopRunSpecific + 536 frame facebook#34: 0x0000000190f62d00 GraphicsServices`GSEventRunModal + 164 frame facebook#35: 0x0000000185bcec98 UIKitCore`-[UIApplication _run] + 796 frame facebook#36: 0x0000000185bd3064 UIKitCore`UIApplicationMain + 124 frame facebook#37: 0x0000000115fbf0bc PRODUCTFramework`main + 200 frame facebook#38: 0x00000001114293d8 dyld_sim`start_sim + 20 frame facebook#39: 0x0000000111506b4c dyld`start + 6000 ``` Reviewed By: rubennorte Differential Revision: D74654157 fbshipit-source-id: 9181bcd28524c71d0ca4620bd630dc0baa172386
cipolleschi
pushed a commit
that referenced
this pull request
Jun 16, 2025
Summary: Pull Request resolved: facebook#51425 # Problem React native's new architecture will allow components to do sync render/events. That means they'll makes synchronous dispatches from main thread to the js thread, to capture the runtime so that they can execute js on the main thread. But, the js thread already as a bunch of synchronous calls to the main thread. So, if any of those js -> ui sync calls happen concurrently with a synchronous render, the application will deadlock. This diff is an attempt to mitigate all those deadlocks. ## Context How js execution from the main thread works: * Main thread puts a block on the js thread, to capture the js runtime. Main thread is put to sleep. * Js thread executes "runtime capture block". The runtime is captured for the main thread. The js thread is put to sleep. * Main thread wakes up, noticing that the runtime is captured. It executes its js code with the captured runtime. Then, it releases the runtime, which wakes up the js thread. Both the main and js thread move on to other tasks. How synchronous js -> main thread calls work: * Js thread puts a ui block on the main queue. * Js thread goes to sleep until that ui block executes on the main thread. ## Deadlock #1 **Main thread**: execute js now: * Main thread puts a block on the js queue, to capture the runtime. * Main thread then then goes to sleep, waiting for runtime to be captured **JS thread**: execute ui code synchronously: * Js thread schedules a block on the ui thread * Js thread then goes to sleep, waiting for that block to execute. **Result:** The application deadlocks | {F1978009555} | {F1978009612} |  ## Deadlock #2 **JS thread**: execute ui code synchronously: * Js thread schedules a block on the ui thread * Js thread then goes to sleep waiting for that block to execute. **Main thread**: execute js now: * Main thread puts a block on the js queue, to capture the runtime. * Main thread then then goes to sleep, waiting for runtime to be captured **Result:** The application deadlocks | {F1978009690} | {F1978009701} |  # Changes This diff attempts to fix those deadlocks. How: * In "execute ui code synchronously" (js thread): * Before going to sleep, the js thread schedules the ui work on the main queue, **and** it posts the ui work to "execute js now". * In "execute js now" (main thread): * This diff makes "execute js now" stateful: it keeps a "pending ui block." * Before capturing the runtime, the "execute js now" executes "pending ui work", if it exists. * While sleeping waiting for runtime capture, "execute js now" can wake up, and execute "pending ui work." It goes back to sleep afterwards, waiting for runtime capture. ## Mitigation: Deadlock #1 **Main thread**: execute js now: * Main thread puts a block on the js queue, to capture the runtime. * Main thread then then goes to sleep, waiting for runtime capture **JS Thread**: execute ui code synchronously: * Js thread puts its ui block on the ui queue. * ***New***: Js thread also posts that ui block to "execute js now". Main thread was sleeping waiting for runtime to be captured. It now wakes up. * Js thread goes to sleep. The main thread wakes up in "execute js now": * Main thread sees that a "pending ui block" is posted. It executes the "pending ui block." The block, also scheduled on the main thread, noops henceforth. * Main thread goes back to sleep, waiting for runtime capture. * The js thread wakes up, moves on to the next task. **Result:** The runtime is captured by the main thread. | {F1978010383} | {F1978010363} | {F1978010371} | {F1978010379} |  ## Mitigation: Deadlock #2 **JS Thread**: execute ui code synchronously: * Js thread puts its ui block on the ui queue. * ***New***: Js thread also posts that ui block to "execute js now". Main thread was sleeping waiting for runtime to be captured. It now wakes up. * Js thread goes to sleep. **Main thread**: execute js now * Main thread sees that a "pending ui block" is posted. It executes the "pending ui block" immediately. The block, also scheduled on the main thread, noops henceforth. * Js thread wakes up and moves onto the next task. **Result:** Main thread captures the runtime. | {F1978010525} | {F1978010533} | {F1978010542} |  Changelog: [Internal] Reviewed By: javache Differential Revision: D74769326 fbshipit-source-id: 854b83ce4e482a4030dc711834ea6c5613091537
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
16 participants
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:
This change makes react-native-mac build with the old architecture using
use_frameworks and static linking
Changelog:
[iOS][Added] - Support for use_frameworks! in the old architecture with
static linking
Test Plan:
Tested locally with RNTester