Hi,
it seems, then when the DLL gets unloaded by the VST host, any spawned threads must have be joined before.
Do I need to close all threads upon every "releaseResources" message or is there any message in between the releaseResources and the destructor of the AudioProcessor (too late to join threads here).
Any help welcome!
Thanks,
ekneos
Your plugin's destructor would be a good place to do that.
Thanks for the fast response.
However, if I try to join threads in the destructor of the class derived from AudioProcessor, it fails (timeout right at the ->join command). An explanation could be that the threads have already been shut down when the DLL has begun unloading.
The problem seems to be known:
https://groups.google.com/forum/#!topic/boost-list/p-kVdNbcw4A
Also this:
"Consider a DLL that creates worker threads as part of its initialization. Upon DLL cleanup, it is necessary to synchronize with all the worker threads to ensure that the data structures are in a consistent state and then terminate the worker threads. Today, there is no straightforward way to completely solve the problem of cleanly synchronizing and shutting down DLLs in a multithreaded environment. This section describes the current best practices for thread synchronizing during DLL shutdown"
https://msdn.microsoft.com/en-us/library/windows/desktop/dn633971%28v=vs.85%29.aspx#general_best_practices
Well I've no idea what the requirements are for your threads or your app, but all the plugin destructors will be called before the DLL is unloaded, so it's a good place to do shutdown tasks.
I could track the problem down to a static class, that somehow disturbed the order or excecution of DLL unloading, thread shutdown and destructors.
I replaced the static member by an SharedResourcePointer and now the threads survive until I can join them in the destructor.
Hope this helps if anybody else has problems with catching their threads in a DLL.
Yeah, statics are completely toxic when writing plugins.
