vanja/yabridge
1
0
Fork 0
mirror of https://github.com/robbert-vdh/yabridge.git synced 2026-06-20 11:02:52 +02:00
Code Issues Packages Projects Releases Wiki Activity

Prevent a deadlock in plugin group handling

Browse Source 
This was a nasty race condition that only seemed to pop up with Spitfire
plugins in REAPER, but it could also happen elsewhere. The
`active_plugins_mutex` was getting locked from the message loop, but the
plugin would block until `effOpen()` had been called. But because the
mutex was locked by the message loop we would never get to handling
`effOpen()`. Passing the pointer directly both removes this unnecessary
locking and fixes the issue.
This commit is contained in:
Robbert van der Helm
2020-12-12 12:44:01 +01:00
parent 33cb5f1efe
commit 712736e74a
3 changed files with 29 additions and 24 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/wine-host/bridges/group.h
+3 -4
View File
@@ -139,15 +139,14 @@ class GroupBridge {
* This check is delayed by a few seconds to prevent having to constantly
* restart the group process during plugin scanning.
*
* @param plugin_id The ID of this plugin in the `active_plugins` map. The
* thread can fetch the plugin's `Vst2Bridge` instance from that map using
* this identifier.
* @param plugin_id The ID of this plugin in the `active_plugins` map. Used
* to unload the plugin and join this thread again after the plugin exits.
*
* @note In the case that the process starts but no plugin gets initiated,
* then the process will never exit on its own. This should not happen
* though.
*/
void handle_plugin_dispatch(size_t plugin_id);
void handle_plugin_dispatch(size_t plugin_id, Vst2Bridge* bridge);
/**
* Listen for new requests to spawn plugins within this process and handle