1

VS2013, C++ I just release dll application. One of dll app function run thread by _beginthread. In normal software flow I use mutex and control threads. Before unregister dll from main application I wait for thread terminating and close handlers.

However there is one case that main application could close without release resources in correct way I mean without waiting for child thread terminating and without close of handlers.

Is there any risk if main application force exit? Is there any risk if I run application and threads again after exit? Is there any risk for OS? Are all threads terminating after main exit?

I know that it is "dirty" solution but for some reason I can’t change that.

Thank you in advance for advices.

Dariusz
  • 11
  • 3

3 Answers3

1

According to Raymond Chen - in Windows systems - if the main thread terminates, your application hangs while all your threads end. This means, no your solution will not work, your thread will freeze your application in the closing state. Also even if your thread would be forcefully terminated on exit, it would not be uninitialized, and - since we are talking about MFC threads here - it would cause your application to leak resources, so pretty please don't do that!

mg30rg
  • 1,311
  • 13
  • 24
  • Interesting! "application hangs while all your threads end" shouldn't mean it hangs forever. I assume, the threads are also terminated by the run-time, are not they? – Valentin H May 21 '15 at 11:06
  • @ValentinHeinitz I strongly suggest to read the linked article on the subject... It clarifies a lot of things I did not have time to explain myself. Also even if the runtime terminates the thread by calling 'TerminateThread()' (or any other forceful means), all resources allocated by the thread gets leaked so it still would be a bad solution. – mg30rg May 21 '15 at 11:32
1

Is there any risk if main application force exit?

Yes! Since thread can have started consistence-sensitive processes.

Is there any risk if I run application and threads again after exit?

Yes! May be previous shutdown crushed the data structure and now you cannot even load data correctly

Is there any risk for OS?

It depends on your business. May be you create a soft for disk-optimization and you are moving clusters while emergency shutdown?

Are all threads terminating after main exit?

Yes! You need foreseen special "join" code that waits accomplishment of threads.

Dewfy
  • 23,277
  • 13
  • 73
  • 121
1

I would say, the behavior is undefined. Too many things may happen, when the application is terminated without having the chance to clean up. This SO question may give some ideas.

This MS article describes TerminateThread function and also lists some implication of unexpectedly terminating the threads (which is probably happened on calling exit):

  • If the target thread owns a critical section, the critical section will not be released.
  • If the target thread is allocating memory from the heap, the heap lock will not be released.
  • If the target thread is executing certain kernel32 calls when it is terminated, the kernel32 state for the thread's process could be inconsistent.
  • 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.

So looks like there is a risk even for the OS

kernel32 state for the thread's process could be inconsistent

Community
  • 1
  • 1
Valentin H
  • 7,240
  • 12
  • 61
  • 111
  • Some non-listed consequences I know of terminating a thread from the outside: If it had the ownership of any Windows handles (file- or named pipe handles, kernel objects, shared memory or even GUI handles which is less likely but possible), those handles might be "leaked" (remain unreleased). If it had any sync object locked/signaled (a named mutex or event, a semaphore etc.), it might remain locked probably preventing a later instance from running. If it was in the middle of a delayed file write it might leave the file in an inconsistent state. It could even harm the page file for gods sake! – mg30rg May 21 '15 at 13:26