mirror of
https://github.com/got-feedBack/feedBack-desktop.git
synced 2026-07-21 12:22:34 +00:00
8354194722
The same finding as the clearChain/remove/moveProcessor fix, in a path I missed on the first pass. CodeRabbit pointed at this line for the wrong reason (it claimed the mutation was unguarded — it is guarded); the real defect is WHERE the guard is taken. LoadVST's macOS branch took a blocking lock_guard on chainMutationMutex on the Node/main thread. On macOS that thread is also JUCE's message thread, and it has no pump — its queue is drained by a libuv timer that only runs when the thread is idle. Meanwhile a LoadPresetWorker holding that mutex on a libuv thread calls JUCE's *synchronous* createPluginInstance, which — when called off the message thread, which is exactly where a worker calls it — posts an AsyncCreateMessage to the message thread and blocks until it runs (juce_AudioPluginFormat.cpp, createInstanceFromDescription). So: main thread blocks on the mutex → the message queue stops draining → the worker's load never completes → the mutex is never released → the app hangs permanently. Adding a VST while a preset load is in flight was enough to trigger it. The in-code comment asserted this was deadlock-safe because "loadVstSandboxAware's JUCE_MAC branch is a synchronous load on the worker itself" — but JUCE's sync load is not synchronous off the message thread, which is what makes the cycle. The plugin INSTANTIATION has to stay on the main thread (JUCE requires it for VST/AU on macOS), so only the mutation moves: it now goes through queueChainSlotMutation(), a slot-id-returning sibling of queueChainMutation(). While the worker waits for the mutex the main thread stays free to drain the queue, so the in-flight load completes and releases it. The branch is portable C++, so it was compile-checked on Linux by forcing the #if; the macOS addon lane is the real gate. |
||
|---|---|---|
| .. | ||
| audio | ||
| main | ||
| renderer | ||
| vst-host | ||