• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 216
  • Last Modified:

Gracefull thread killing when App ends

My app will sometimes create a CWinThread-derived thread to go do some work.  It is technically a UI thread, since it has a window, used to monitor what is going on, but it does not get any user input.

I have the thread set up with the m_bAutoDelete to TRUE, so that once the tread is finished it deletes itself.  This works quite well until I try quitting the program while the thread is still running.  When this happens the thread gets killed, and memory leaks abound.

So I thought, when the app is quitting, I could somehow inform the thread that it is time to die.  However, because the thread can destroy itself, I don't know if I have a thread still running or not.  The thread destroys itself, but my pointer still has a value, alas one that is useless.

How can I figure out if the thread is still running when I quit, and if so tell it to quit before the app finishes?
0
carlosn
Asked:
carlosn
  • 3
  • 2
1 Solution
 
carlosnAuthor Commented:
Edited text of question
0
 
majorjohnCommented:
When you quit the application all threads of this will be automaticaly killed. Now your problem with memory leaks can be easily solved by only puting sleep(NNNN) in your WM_ONCLOSE member function of CFrmWnd Class. NNNN denotes milliseconds sleep(2000). That depends on your user interface thread. You try it out with changing the values of NNN and see in debug mode whether  your user interface thread is giving any memory leak or not. Please keep updating the interaction.
0
 
carlosnAuthor Commented:
I thought about doing this, but I would like some option that is a bit more graceful.  I'd rather not have an absolute wait, especially since most of the time the thread is already dead anyway.  The issue is only when the user happens to kill the app during the brief time the thread is running.
0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
mikeblasCommented:
There's no silver bullet here.

You have to code your threads to watch for an event or look for a flag. When they see that signal, they should exit.

When you want to exit, set that flag and then wait for the threads to stop executing. You can wait for a thread by calling WaitForSingleObject() (or any of its friends) on the handle of the thread.

Don't ever, under any circumstances, call the TerminateThread() API.

B ekiM

0
 
carlosnAuthor Commented:
I see what you are getting at here.  I hadn't thought of that approach.  My only concern, if the thread deletes itself after completion, there isn't a handle to wait on any more.  Say I had a thread pointer 'pThread'

The thread executed, and then deleted itself because of the m_bAutoDelete = TRUE.  What happens if I try a WaitOnSingleEvent(pThread->m_hThread);  It seems that there is a slim chance that whatever happens to lie in the memory once occupied by the variable could point to a waitable object, though I guess that is fairly slim.

Carlos
0
 
mikeblasCommented:
In actuality, there is.  The thread handle is valid until someone calls CloseHandle() on it.

The CWinThread object, on the other hand, can delete itself as you describe. And, for that reason, m_bAutoDelete is of dubious value in the class.

B ekiM
0

Featured Post

How to Use the Help Bell

Need to boost the visibility of your question for solutions? Use the Experts Exchange Help Bell to confirm priority levels and contact subject-matter experts for question attention.  Check out this how-to article for more information.

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now