Is it necessary to explicitly stop all threads prior to exiting a Win32 application?

Question

I have a Win32 native VC++ application that upon entering WinMain() starts a separate thread, then does some useful job while that other thread is running, then simply exits WinMain() - the other thread is not explicitly stopped.

This blog post says that a .NET application will not terminate in this case since the other thread is still running. Does the same apply to native Win32 applications?

Do I have to stop all threads prior to exiting?

Answer 1

short answer : yes

Answer 2

Yes you have, otherwise your application may hang.

I recommend reading Raymond Chen's excellent blog posts on this topic:

The old-fashioned theory on how processes exit

Quick overview of how processes exit on Windows XP

How my lack of understanding of how processes exit on Windows XP forced a security patch to be recalled

During process termination, the gates are now electrified

Answer 3

No, when WinMain returns, the process will be terminated, and this means all threads spawned by the process should be terminated though they might not be closed gracefully.

However, it is possible that a primary thread is terminated while the other threads are running, resulting in the application is still running. If you call ExitThread (not exit or ExitProcess) in WinMain, and there are running threads (eventually created by the primary thread), then, you may observe this behavior. Nonetheless, just return in WinMain will call ExitProcess, and that means all threads are should be terminated.

Correct me if it's wrong.

Answer 4

The short of it is: For a native Win32 process to terminate, one of two conditions must be met:

• Someone calls ExitProcess or TerminateProcess.
• All the threads exit (by returning from their ThreadProc (including the WinMainEntryPoint that is the first thread created by windows)), close (by calling ExitThread), or terminated (someone calls TerminateThread).

(The first condition is actually the same as the 2nd: ExitProcess and TerminateProcess, as part of their cleanup, both call TerminateThread on each thread in the process).

The c-runtime imposes different conditions: For a C/C++ application to terminate, you must either:

• return from main (or WinMain).
• call exit()

Calling exit() or returning from main() both cause the c-runtime to call ExitProcess(). Which is how c & c++ applications exit without cleaning up their threads. I, personally, think this is a bad thing.

However, non trivial Win32 processes can never terminate because many perfectly, otherwise reasonable, Win32 subsystems create worker threads. winsock, ole, etc. And do not provide any way to cause those threads to spontaneously close.

Answer 5

I think you can first close all your windows(so the user won't see your application), and then set a flag for exit, your thread should check the flag periodicly, and once found set, the thread should return.

after set the flag, your main thread could call ::WaitForSingleObject() or ::WaitForMultipleObjects() for a while (say, three seconds), if the thread(s) not return, just kill them by ::TerminateThread().