The problem with TerminateThread

[dullboy]

I heard that a disadvantage by calling a TerminateThread to terminate a thread is that when the thread ends, the system doesn't notify any DLLs attached to the process owning the thread. I don't see any problems with that. Can any guru here explain what the potential problems are there? Thanks for your inputs.

[UnfitElf]

Its an interesting question. Ill be watching for guru's replies, this can be quite a detailed topic.

How do you know the DLL doesn't do some essential cleanup when its unloaded? There are numerous situations where it could cause problems. There are also other issues such as are local objects wont have their destructors called. If you will specifically get problems doing this or not depends on your application however, it is deemed bad practice.

Are you specifically wanting information about the DLL's not being notified or are you wanting information generally on why its a bad idea?

My question to you is why would you call TerminateThread? Its extremely easy to avoid (up until the point of last resort) and it will insure everything "plays nice".

Something like the following, most error checking left out but will give general idea:


... myThread(void * pData)
{
bool bRun = true;
while (bRun)
{
if (::WaitForSingleObject(hThreadClose, 50) == WAIT_OBJECT_0)
{
bRun = false;
}
else
{
// Do somthing.
}
}
return 0;
}

void CloseThread()
{
::SetEvent(hThreadClose);
if (::WaitForSingleObject(hThread, 2000) != WAIT_OBJECT_0)
::TerminateThread(hThread);
hThread = 0;
}



Regards

[MikeAThon]

I heard that a disadvantage by calling a TerminateThread to terminate a thread is that when the thread ends, the system doesn't notify any DLLs attached to the process owning the thread. I don't see any problems with that. Can any guru here explain what the potential problems are there? Thanks for your inputs.
That is certainly one danger in use of TerminateThread. But the documentation for this function lists many other dangers. Can you find them? Do you understand them?

[dullboy]

I know there is another danger related to thread stack. Could you explain the danger I mentioned in my first post? Thanks for your inputs.
That is certainly one danger in use of TerminateThread. But the documentation for this function lists many other dangers. Can you them? Do you understand them?

[VictorN]

Did you read this FAQ (http://www.codeguru.com/forum/showthread.php?t=305166)?

[dullboy]

It is a nice article. Thank you. This article mentioned that "If the target thread is manipulating the global state of a shared DLL, the state of the DLL could be destroyed, affecting other users of the DLL. ". I wander what exactly global state of a shared DLL is? Can you give me an example? Also I have another question. When a thread is completing a lengthy operation, usually we can call TerminateThread to terminate the thread, I wander in that case, can we still use ExitThread to terminate the thread? Thanks for your inputs.
Did you read this FAQ (http://www.codeguru.com/forum/showthread.php?t=305166)?

[VictorN]

When a thread is completing a lengthy operation, usually we can call TerminateThread to terminate the thread, I wander in that case, can we still use ExitThread to terminate the thread? Thanks for your inputs.Usually, we must not call TerminateThread at all.
Thread must exit itself (by return from a thread procedure in the case of a worker thread or by calling PostQuitMessage(0) in the case of UI thread)

[VictorN]

... what exactly global state of a shared DLL is? Can you give me an example? Googly can give you a lot of information (http://www.google.com/search?num=20&hl=en&newwindow=1&rlz=1T4GGLJ_enCH344&q=%22global+state%22+of+a+shared+DLL&btnG=Search&aq=f&aqi=&aql=&oq=&gs_rfai=)