只要不是永远，在DllMain (PROCESS_DETATCH)中等待是可以的吗?

Is it ok to wait in DllMain (PROCESS_DETATCH) as long as its not forever?

本文关键字：等待 DETATCH 永远要不是 DllMain PROCESS 更新时间：2023-10-16

我正在编写一个通过USB与硬件通信的接口Dll。为了完全满足硬件的定时要求(防止它在没有操作消息等的情况下超时)，我在调用"Open()"方法时立即为每个惰性初始化创建一个工作线程。当我的"close()"方法被调用时，我设置了一个名为"terminate"的事件，该事件由工作线程监控，并等待工作线程终止。终止需要几百毫秒，因为需要与硬件交换一些消息。

到目前为止一切都很好，唯一的问题是当一个程序卸载Dll没有调用我的"Close()"方法…我通过在DllMain (PROCESS_DETATCH)中设置"终止"事件来解决这个问题，我很确定我可以这样做，并且仍然完全填补最佳实践。唯一的问题是，如果Dll在没有调用close的情况下卸载，但在旧的工作线程终止之前再次重新加载，我会在加载我的Dll的过程中导致超时，因为我正在等待旧的工作线程完成。

所以这里是我的问题:将等待工作线程终止在DllMain (PROCESS_DETATCH)超时说500毫秒导致任何问题，如果我只做它时，一个工作线程存在，只有当我被卸载(通过freeLibrary)，而不是当我的整个进程被终止，我通过查看lpvReserved参数测试?

还有:有没有更好的方法来解决我的问题?

唯一会发生的事情是使调用FreeLibrary的线程(FreeLibrary不是异步的，它等待返回值)等待只要你的模块正在卸载。

我做了一些DLL，有时甚至像DLLMain中的while(!IsDebuggerAttached()){}这样的循环附加/分离，我测试的程序的行为就像他们需要的一样。

至于其他问题的解决方案:除了DLLMain附加/分离之外，为什么还需要其他具有相同功能的东西?

我在我的PROCESS_DETACH中实现了等待，它起初工作，但在一个角落的情况下，它最终导致了问题。问题是我们的调试输出设置加载了一个专有的DLL，以便在调试输出中包含版本信息。如果我们的DLL快速加载和卸载，并且在后台有足够的时间来读取这个版本信息，那么它可能会在进程等待PROCESS_DETACH时发生，从而导致死锁。

对于未来，我已经决定不再等待dlmin中的任何东西，因为我等待的任何东西都可能在某些角落的情况下或在其他人向某些类添加功能后被触摸，导致加载器锁上死锁。