From 68c7b9b081343ace27238ea3c23d6513c2e436ac Mon Sep 17 00:00:00 2001 From: Robbert van der Helm Date: Thu, 17 Dec 2020 23:32:56 +0100 Subject: [PATCH] Destroy VST3 objects within the main IO context --- src/wine-host/bridges/vst3.cpp | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-) diff --git a/src/wine-host/bridges/vst3.cpp b/src/wine-host/bridges/vst3.cpp index 62267f3c..f857521e 100644 --- a/src/wine-host/bridges/vst3.cpp +++ b/src/wine-host/bridges/vst3.cpp @@ -16,8 +16,11 @@ #include "vst3.h" +#include + #include "../boost-fix.h" +#include #include #include "vst3-impls/host-application.h" @@ -102,9 +105,24 @@ void Vst3Bridge::run() { }, [&](const Vst3PluginProxy::Destruct& request) -> Vst3PluginProxy::Destruct::Response { - std::lock_guard lock(object_instances_mutex); - object_instances.erase(request.instance_id); + std::promise latch; + boost::asio::dispatch(main_context.context, [&]() { + // Remove the instance from within the main IO context so + // removing it doesn't interfere with the Win32 message loop + std::lock_guard lock(object_instances_mutex); + object_instances.erase(request.instance_id); + + latch.set_value(); + }); + + // XXX: I don't think we have to wait for the object to be + // deleted most of the time, but I can imagine a situation + // where the plugin does a host callback triggered by a + // Win32 timer in between where the above closure is being + // executed and when the actual host application context on + // the plugin side gets deallocated. + latch.get_future().wait(); return Ack{}; }, [&](Vst3PluginProxy::SetState& request)