Click here to Skip to main content
Rate this: bad
good
Please Sign up or sign in to vote.
See more: MFC multithreading
Hello,
 
I have an application that runs on a single thread and carries out some calculation operation. My question is what would cause the application to quit the thread automatically and go to the exitinstance() function and exits out without me giving it a command to exit the thread. Any possible suggestions on why this is happening?
Posted 15-Mar-13 3:25am
Comments
nv3 at 15-Mar-13 8:30am
   
Why don't you set a breakpoint in ExitInstance and see what's going on? Probably some kind of initialization problem.
Mobile.Instinct at 15-Mar-13 8:32am
   
I did.. it comes in exitinstance but it is not supposed to till the thread is stopped. Could you suggest me anything that would make the thread to stop?
nv3 at 15-Mar-13 8:56am
   
Please use the reply button of the message you are responding to; that lets the other person know by e-mail that someone has sent a reply.
 
The problem might be that your InitInstance function of the thread returns false. If you have set a breakpoint, use the CallStack window see where the call of ExitInstance comes from. This way you can easily see the cause.
CPallini at 15-Mar-13 8:41am
   
Probably you should show us some code.
Sergey Alexandrovich Kryukov at 15-Mar-13 11:34am
   
I think the OP concern is clear to me; I answered in detail...
—SA
Sergey Alexandrovich Kryukov at 15-Mar-13 11:13am
   
Please disregard my previous comment (removed). You need to capitalize ExitInstance to make it understandable. C++, by the way, is case sensitive.
—SA

1 solution

Rate this: bad
good
Please Sign up or sign in to vote.

Solution 1

This is one of the difficult problems. When you exit the application, all other threads should exit their thread functions, otherwise they will hold your application process from terminating.
 
The problem appears when the thread function "never returns", which is a very usual case.
 
The usual technique is returning the thread function in cooperative manner. In other words, the thread should exit this function by itself. One way to do it is having the "exit flag" variable set by the UI thread and checked by the other thread(s) periodically. In more complex cases, the check is done in the functions deeper on stack; then the perfect way to unwind the stack would be throwing a special "exit" exception (any distinct object thrown would be fine; all you need from it is being different from all other cases of exceptions); by the way, all exceptions are usually should be caught of the very top stack frame of the stack of each thread.
 
I do understand how ugly this solution is, but this is the usual technique. Polling is always a performance hit and a development/support hassle. But other techniques are considered dangerous.
 
Now, there is an advanced technique of safe thread abort developed and published by one Microsoft developer. Unfortunately, I don't have a reference at this time, but I implemented it and know every detail of implementation and functionality. Very few people know that work, but the approach itself eventually made the way to .NET which you don't use. It uses preemptive nature of the Windows threading. I mention it for completeness but don't want to explain it right now, because: 1) I don't believe you are going to implement it in practice, this is a very low-level method; 2) the approach is based on fully documented but not portable Windows API; in other words, you would need to have different implementations for different CPUs; 3) the safety of this approach used to cause furious flame wars (even in discussion of much more stable .NET thread abortion) I don't want to get in; I am personally sure that the method is very safe and reliable, but I will agree that even the use of it requires very good understanding of the technique by the developer using it, otherwise the technique will cause the trouble; my ultimate argument in favor of the technique is that there are many other techniques which also require deep understanding and are dangerous otherwise, but still they don't cause flame wars.
 
If you are curious, I'll give you more detail.

 
[EDIT]
 
See also my past answer: Close correcly the thread inside a dll[^].
 
—SA
  Permalink  
v4
Comments
Mobile.Instinct at 15-Mar-13 11:56am
   
I got the jist of what you mean to say and I am working on making it right. If I am still unable to fix the issue, then I'll give you a buzz but thanks a ton for your answer.
Sergey Alexandrovich Kryukov at 15-Mar-13 12:58pm
   
Good. If you have further questions, you are welcome to ask.
If you see it's reasonable, please don't forget to accept the answer formally (green button) — thanks.
—SA
CPallini at 15-Mar-13 12:10pm
   
Yes, I think you understood the OP issue, my 5.
Sergey Alexandrovich Kryukov at 15-Mar-13 12:58pm
   
Thank you, Carlo.
—SA

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
0 OriginalGriff 200
1 George Jonsson 175
2 Kornfeld Eliyahu Peter 169
3 PIEBALDconsult 110
4 Richard MacCutchan 85
0 OriginalGriff 6,080
1 DamithSL 4,648
2 Maciej Los 4,087
3 Kornfeld Eliyahu Peter 3,624
4 Sergey Alexandrovich Kryukov 3,294


Advertise | Privacy | Mobile
Web04 | 2.8.141220.1 | Last Updated 15 Mar 2013
Copyright © CodeProject, 1999-2014
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100