[MFC] Keep thread alive until application exits
-
Hi, I use the CWinThread class to have my CDialog GUI stay responsive while doing some lengthy calculation. However, my thread needs to stay alive, since it can receive some notification anytime while my application runs. The problem I have is that after InitInstance is done, my thread automatically enters the ExitInstance method, which I do not want. However, I want my thread to stay alive until I close my CDialog, and then enter ExitInstance. Any idea how this can be performed? Thanks alot.
If you need to perform a lengthy calculation, spawn a worker thread and let it do that. The UI thread should not be burdened with anything else but responding to the user.
"Real men drive manual transmission" - Rajesh.
-
Absolutely! I've actually seen people overriding the run method and squeeze in an infinite loop there. When I tell them "that's what it already does, may be what you need is a worker thread?", they'll be like "oh yeah, that makes sense". A lot of people using spawning UI threads don't actually know that they're spawning a, well, UI thread.
"Real men drive manual transmission" - Rajesh.
:laugh: I use CWinThreads quite a bit... I actually like them, they're easy to use and communicate with...
-
From your description it sounds like you have your threads backwards. Your doing the work in a UI thread and trying to spawn another UI thread to keep your UI active. In fact the UI thread should start a worker thread to do the lengthy operation. Then the UI thread can continue to service the user actions.
If you vote me down, my score will only get lower
Excellent answer, Roger.
"Real men drive manual transmission" - Rajesh.
-
From your description it sounds like you have your threads backwards. Your doing the work in a UI thread and trying to spawn another UI thread to keep your UI active. In fact the UI thread should start a worker thread to do the lengthy operation. Then the UI thread can continue to service the user actions.
If you vote me down, my score will only get lower
The UI name is simply a naming convention that MS picked up a long time ago, it doesn't necessarily mean that a CWinThread needs to work with a user interface. Its useful when you need a working thread that's persistent, meaning it doesn't do a job then end.
-
Absolutely! I've actually seen people overriding the run method and squeeze in an infinite loop there. When I tell them "that's what it already does, may be what you need is a worker thread?", they'll be like "oh yeah, that makes sense". A lot of people using spawning UI threads don't actually know that they're spawning a, well, UI thread.
"Real men drive manual transmission" - Rajesh.
-
The UI name is simply a naming convention that MS picked up a long time ago, it doesn't necessarily mean that a CWinThread needs to work with a user interface. Its useful when you need a working thread that's persistent, meaning it doesn't do a job then end.
If you're implying that "UI thread" is some kind of an inappropriate name, I can't agree with you more. I've used these "UI" threads in several instances where there's no UI. For example, if I needed some kind of a queued event processing mechanism within my program that will process requests in the order they were received, then UI thread would be a quick and reliable way to do it. :) BTW, Roger is correct in saying that the OP should rather delegate lengthy tasks to a background worker, and not bother the main thread that processes the dialog UI events.
"Real men drive manual transmission" - Rajesh.
-
If you're implying that "UI thread" is some kind of an inappropriate name, I can't agree with you more. I've used these "UI" threads in several instances where there's no UI. For example, if I needed some kind of a queued event processing mechanism within my program that will process requests in the order they were received, then UI thread would be a quick and reliable way to do it. :) BTW, Roger is correct in saying that the OP should rather delegate lengthy tasks to a background worker, and not bother the main thread that processes the dialog UI events.
"Real men drive manual transmission" - Rajesh.
Exactly! :-D Don't know exactly where that name started, but it stuck apparently. Should be more of a "Persistent thread" or something similar.
-
Before creating the thread, create an "Event" object, closed, not auto-reset. When the thread is ready to exit, use WaitForSingleObject() to wait for the event to be triggered. When the dialog closes, have use SetEvent() to tell the thread that it is ok for it to exit now.
CWinThreads don't require this... you can WaitForSingleObject() on the thread handle itself after you've asked the thread to go down with a WM_QUIT message.
-
CWinThreads don't require this... you can WaitForSingleObject() on the thread handle itself after you've asked the thread to go down with a WM_QUIT message.
In my opinion, interthread activities should be explicitly stated rather than rely on side effects of other things. A "permission to exit" signal is one way of formalizing those activities. "Permission to start" is another. The fact that a thread was created doesn't necessarily mean that it can immediately being doing processing. My threads always go through several stages: 1) Initialization at the start address of the thread 2) Signals an "initialization done" event to allow the main thread to create more, knowing that any data structures, other events / objects are created and that the created thread is ready to run 3) Waits for a "permission to start" event. This allows the main thread to delay start of the thread until other threads are created and ensures that subsequent threads have created their objects that may be necessary for interthread communication to work. 4) enters the "run state" where it is now doing its job 5) "permission to exit" is optional and only when you want the "dance of the threads" to end in an orderly fashion. You want this orderly approach to startup and shutdown to ensure that if you create many threads, some of which need to communicate with each other, those threads do not run into timing problems and access objects that may not be created / initialized yet by other threads. Also, I have no idea why you downvoted my answer, it was not wrong, just not to your liking.
-
In my opinion, interthread activities should be explicitly stated rather than rely on side effects of other things. A "permission to exit" signal is one way of formalizing those activities. "Permission to start" is another. The fact that a thread was created doesn't necessarily mean that it can immediately being doing processing. My threads always go through several stages: 1) Initialization at the start address of the thread 2) Signals an "initialization done" event to allow the main thread to create more, knowing that any data structures, other events / objects are created and that the created thread is ready to run 3) Waits for a "permission to start" event. This allows the main thread to delay start of the thread until other threads are created and ensures that subsequent threads have created their objects that may be necessary for interthread communication to work. 4) enters the "run state" where it is now doing its job 5) "permission to exit" is optional and only when you want the "dance of the threads" to end in an orderly fashion. You want this orderly approach to startup and shutdown to ensure that if you create many threads, some of which need to communicate with each other, those threads do not run into timing problems and access objects that may not be created / initialized yet by other threads. Also, I have no idea why you downvoted my answer, it was not wrong, just not to your liking.
Chuck O'Toole wrote:
Also, I have no idea why you downvoted my answer, it was not wrong, just not to your liking.
CWinThreads aren't used in this fashion... besides, trace back on your other solutions... I'm sure I've upvoted you numerous times (I know I have). Keep up the responses, I'm sure you'll get plenty more :thumbsup: from me.
-
Hi, I use the CWinThread class to have my CDialog GUI stay responsive while doing some lengthy calculation. However, my thread needs to stay alive, since it can receive some notification anytime while my application runs. The problem I have is that after InitInstance is done, my thread automatically enters the ExitInstance method, which I do not want. However, I want my thread to stay alive until I close my CDialog, and then enter ExitInstance. Any idea how this can be performed? Thanks alot.
I briefly talk about this in this article.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Some people are making such thorough preparation for rainy days that they aren't enjoying today's sunshine." - William Feather