fix(🍏): run CAMetalLayer operation on main thread#280
fix(🍏): run CAMetalLayer operation on main thread#280wcandillon wants to merge 1 commit intomainfrom
Conversation
|
These changes are still pending release, huh? |
|
yes we are not 100% of the approach we want to take here yet. |
| void _configure() { | ||
| void _invokeOnMainThread(const std::function<void()> &task) { | ||
| #ifdef __APPLE__ | ||
| RunOnMainThreadSync(task); |
There was a problem hiding this comment.
This is probably not entirely safe. The caller holds _mutex, but the main thread might itself be blocked waiting for _mutex.
Example, just after a background thread takes _mutex and then wants to dispatch to the main thread:
- RN updates view props
- RN calls (on the UI thread)
-[WebGPUView updateProps:oldProps:] WebGPUViewcalls-[MetalView configure]-[MetalView configure]callsSurfaceRegistry.switchToOnscreen()SurfaceRegistry.switchToOnscreen()tries to take_mutexand blocks
In this scenario, the dispatch_sync_f() to the main thread will deadlock.
I think this needs to move to a queue-based system where changes to the surface and/or configuration need to be queued up and then applied in order (which must happen on the main thread on Apple platforms).
|
Left you a comment — I think this approach will deadlock if RN reconfigures view props on the main thread at the same time as the synchronous dispatch. A queue-based system might be smarter to apply all surface/configuration changes in order on the main thread. |
3 participants
fixes #244