c ++/cli程序集加载一个产生多个CLR线程的C#组件; 如何阻止这些线程重新进入C++/CLI入口点？

Question

我有一个使用以下组件构建的C/C++应用程序

1. 本机C/C++应用程序(单线程消息泵,典型的Win32 UI应用程序),静态链接(2)
2. 本机C/C++ Lib/DLL,它在运行时动态加载(3)
3. 用/ clr编译的C++/CLI DLL包装C#程序集(4)
4. AC#assembly使用TPL并具有后台定时器,全部通过静态单例方法公开

我的问题是:C#assembly产生异步I/O线程以响应来自父应用程序的调用,并在后台使用一对System.Threading.Timer实例.

这些线程继续附加本机C/C++应用程序(1)并引起一些副作用,例如COM初始化问题.

这是C#组件运行时输出窗口的样子,我可以看到这些线程在运行时附加到C++/CLI DLL(3)入口点.

我的问题是:如何从C/C++应用程序中防火这些C#线程？我不希望这些线程能够继续调用加载它的本机代码的入口点.

到目前为止,我们能够提出的最好的解决方法是运行所有在他们自己的独立Win32线程(可以工作)中调用C++/CLI/C#dlls(3和4)的代码,但我会很感激任何其他建议!

Answer 1

这完全正常.每当线程开始运行时,就会调用您的DllMain()入口点.无论是谁创建了线程,它都发生在由本机代码启动的线程以及托管代码中.DLL_THREAD_ATTACH线程开始运行时,您将收到通知. DLL_THREAD_DETACH当它再次停止运行时.

这些回调的目的是帮助您设置线程本地存储.你通常完全忽略它们.您可以要求Windows不要打扰它,在DLL_PROCESS_ATTACH通知处理程序中调用DisableThreadLibraryCalls().

这纯粹是指优化,而不是错误的解决方法.没有可能的情况,这些回调应该导致COM问题,我怀疑你真的发现了问题的根源.除非你的DllMain()函数忽略了fdwReason参数,否则这将是不好的.