DLL_THREAD_DETACH is called when a thread is exiting in a clean manner. Do you have such a thread in your process you know it's doing this ?
DLL_THREAD_DETACH is not called when a thread is terminated.
I would suggest also to remove the Sleep(2000) line and move the 2000 timeout inside WaitForSingleObject() call, it's more efficient.
Also, after SetEvent(this->stopFlag), I would check that the thread has exited before closing the event handle. (for example with a WaitForSingleObject(this->threadHandle, sometimeout))
This is becouse the thread might be executing the Sleep(2000) while the event handle is closed, therefore WaitForSingleObject(this->stopFlag,0) would never return WAIT_OBJECT_0 and you'll never break the while() loop.
The function which contains the while block runs in a separate thread.
my goal is to break the while loop when the dll is detach.
i want to close the thread by myself and not by the os(which will cause terminate).
Code:
void myThread::startMonitor()
{
while(true)
{
//Do something every 2 seconds
if (WAIT_OBJECT_0 == WaitForSingleObject(this->stopFlag,2000))
break; //break the while and close the thread
}
}
what i am trying to do here is to set the stopFlag (event) to Single when the process is detach.
what i'm doing wrong?
The layout of your code is mostly Ok.
However, if you want to cleanly stop the thread when the dll is unloaded, you should use DLL_PROCESS_DETATCH. So I would move this line _monitor.endThread() in DLL_PROCESS_DETACH. Remains valid the previous post about waiting for the thread's handle after you set the event to signaled, like so:
The purpose of that WaitFor... is to give some time to the thread before the stopFlag is closed.
You could also use GetThreadExitCode() (or something like this), but in this case I don't think is worth it.
>> my goal is to break the while loop when the dll is detach
That would be DLL_PROCESS_DETACH. However, threads can not actually start or exit while in the context of DllMain. So you can signal the exit event, but there's no point in waiting on the thread handle because it will never become signaled - until your out of DllMain - but after a DLL_PROCESS_DETACH due to process termination, the thread's already been killed anyway.
Well, in light of the latest info provided by Codeplug, you'd probably be better off by adding some Initialize/Uninitialize functions to your dll, do thread signaling/waiting in Uninitialize() which you call before you exit the process.
I dont understand, how can i notify my theads something if they are
already got killed.
i need to close these threads when the dll is about to unload.
when DLL_PROCESS_DETACH got called the threads are already dead.
and for some reason DLL_THREAD_DETACH doesn't get called at all.
Add 2 functions to your dll and export them.
Initialize { monitor.startThread(); } and
Uninitialize () {monitor.stopThread(); }.
Call Initialize() from the process after the dll is loaded. Call Uninitialize() before you unload the dll.
Thus you avoid DLL_ATACH/DETACH, and cleanly exit the thread.
>> when DLL_PROCESS_DETACH got called the threads are already dead.
That's only when the process is terminating. It could be the result of an explicit call to FreeLibrary() - in which case your thread would still be running.
>> what am i supposed to do?
Ideally, you would have a MyDll_Init() and MyDll_Shutdown() - which clients of the DLL would need to call.
Control your dll load/unload. I can't believe the whole situation: you just allow your dll come and go. Instead you have to make a contract: the client app must initialize the dll before using it, and unitialize before unloading it. Explicitly.
* The Best Reasons to Target Windows 8
Learn some of the best reasons why you should seriously consider bringing your Android mobile development expertise to bear on the Windows 8 platform.