aitForSingleObject exit for timeout only, thread is not signaled
Hello everybody,
I am working with a thread for implementing a timer. If the thread is started / exited directly from an application (standard exe) everything works fine, but if I create and exit it from within a DLL loaded by the application, WaitForSingleObject fails to detect the thread exit. Why is that?
WaitForSingleObject exits with WAIT_TIMEOUT after 5 seconds instead of WAIT_OBJECT_0 (the one that I expect) and then I am forced to kill the thread with
TerminateThread.
I used the scroll key LED and Dbgview (OutputDebugString) for debugging.
In case someone were so kind to help me I attached a sample Borland C++ Builder project with the code below (including a testing console for loading / unloading the DLL library).
Anyone can help?
Thank you very much in advance!!!!!!
Re: aitForSingleObject exit for timeout only, thread is not signaled
Your problem is: thread does not actually unload on kernel level until dll process detach completed. See the sample when ThreadDestroy is called before freeing library - the thread exit gets detected fine.
Last edited by Igor Vartanov; June 23rd, 2010 at 12:05 PM.
Re: WaitForSingleObject exit for timeout only, thread is not signaled
Igor,
thank you for your reply.
In your opinion, do you think there might be a clean solution relying only on FreeLibrary, i.e. doing everything that is needed to exit the thread and detect thread exit when the DLL is unloaded, or the only solution is telling the DLL user to call a specific DLL function before unloading the DLL with FreeLibrary?
Re: WaitForSingleObject exit for timeout only, thread is not signaled
Frankly, your sample is evidently artificial, and it's hard to say what exact scenario you do expect in a field. For example, I don't see any good in running the thread initially suspended and resume it anyway after a couple of CPU cycles. And the same way I do not understand why you should wait for thread quit. Is it just for paranoidly killing it?
On the other hand, in case this would be some SDK dll, it seems absolutely normal to instruct its user to (un)initialize it at a proper moment.
* 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.