in a VST3 plugin scanning scenario each plugin is loaded, its component is initialized, success is reported to a master app/thread and then the instance can be closed. The SmartPointers implemented within the VST3 SDK allow the safe removal of all the structs/classes; And the destructor ~Win32Module() correctly calls FreeLibrary, which returns non-zero, indicating, that the operation succeeded. But the plugin DLL still remains loaded in some cases. (Visual Studio debugging still shows them in their “module” section). And the reason for that seem to be some worker threads created by that plugin. Those worker-threads are shown in the “threads” section in the Visual Studio debugger.
Is there a way to instruct the plugin to exit all its worker-threads without being forced to use TerminateThread. If not, how to obtain all the worker-thread ids from such a plugin?
Calling component->setActive(false); makes no difference.
Also enumerating all current process’s threads and then using GetThreadDescription gives no result, most of the worker-threads have no names, and even if they would have names, how to ensure to find the belonging threads to the instance, which should be closed?
Thank you!