Terminating a thread
-
"In my ThreadParam struct I added a variable bool Stop. When I start the thread I set stop to false and in the while loop I use an if statement to check for Stop. If it is true I break out of the while loop so the thread can close safely. I change Stop to true in the WM_CLOSE message of the MAIN GUI interface--No success." First thing that popped into my head was "is 'Stop' a volatile variable and is it a managed resource? (Do you use a critical section to control who is accessing it? Suggestion: If this is how you want to stop your thread this could work. I would recommend using a short instead of a bool. This way it can have states. Ie. 0=Thread running, 1=Request a stop and 2=Thread stopped. Then you GUI thread can check this before actually closing the window. Second thing that popped into my head is that Stop shold work uness the code you are using in your while loop is blocking and thus never checking Stop. Matt Gullett
Just clarifying the acutual code in the while loop now is:
listen(sListen, 5);
while (1)
[
if (pThreadData->Stop)
break; //Just exit the while loop and let the thread close out
]closesocket(sListen);
WSAcleanup();
return 0;
It is just bare minimum because I'm trying to see why I get the memory leak. I have nothing else in the while loop pertaining to the socket. HomeNuke ---- "Nuke'd Your Home, Yet?" Run your own PostNuke based web server from home http://www.homenuke.com
-
Just clarifying the acutual code in the while loop now is:
listen(sListen, 5);
while (1)
[
if (pThreadData->Stop)
break; //Just exit the while loop and let the thread close out
]closesocket(sListen);
WSAcleanup();
return 0;
It is just bare minimum because I'm trying to see why I get the memory leak. I have nothing else in the while loop pertaining to the socket. HomeNuke ---- "Nuke'd Your Home, Yet?" Run your own PostNuke based web server from home http://www.homenuke.com
There's no reason for your thread to block with your example except that your thread is taking up all the CPU. Try putting a Sleep(0) in your loop. Make sure your memory leak is not from "pThreadData" :-O - Greatest invention : "The Microchip!"
-
There's no reason for your thread to block with your example except that your thread is taking up all the CPU. Try putting a Sleep(0) in your loop. Make sure your memory leak is not from "pThreadData" :-O - Greatest invention : "The Microchip!"
I'll try putting a sleep call in there. I'm hoping that pThreadData is not the leak since I have this pointing to a member variable in the outer class that is defined as my ThreadData struct. I am *assuming* that since the variable is declared on the stack, and space not dynamically allocated, it goes out of scope, and it's memory released, when the class does. Please let me know if this assumption is not correct :) **UPDATE**just thinking about it pThreadData is not the leak because if I remove the while loop there is no memory leak detected. The leak detected is object CWinThread hopefully this additional information is helpful. HomeNuke ---- "Nuke'd Your Home, Yet?" Run your own PostNuke based web server from home http://www.homenuke.com
-
I'll try putting a sleep call in there. I'm hoping that pThreadData is not the leak since I have this pointing to a member variable in the outer class that is defined as my ThreadData struct. I am *assuming* that since the variable is declared on the stack, and space not dynamically allocated, it goes out of scope, and it's memory released, when the class does. Please let me know if this assumption is not correct :) **UPDATE**just thinking about it pThreadData is not the leak because if I remove the while loop there is no memory leak detected. The leak detected is object CWinThread hopefully this additional information is helpful. HomeNuke ---- "Nuke'd Your Home, Yet?" Run your own PostNuke based web server from home http://www.homenuke.com
Fine, I thought you allocate your ThreadData with "new" or malloc... If you are using a CWinThread object, in your case, Set "m_bAutoDelete = TRUE" after starting your thread. By the way, it's not necessary to use CWinThread since what you want is a working Thread. - Greatest invention : "The Microchip!"
-
Fine, I thought you allocate your ThreadData with "new" or malloc... If you are using a CWinThread object, in your case, Set "m_bAutoDelete = TRUE" after starting your thread. By the way, it's not necessary to use CWinThread since what you want is a working Thread. - Greatest invention : "The Microchip!"
Ah...that could be the step I'm missing :) I'm not inheriting from CWinThread so to speak, but it is what is returned when you call AfxBeginThread() :) I was told not to call CreateThread from within an MFC function or be forewarned about doing so...I don't even know if that is correct now since I have gone through several source codes that utilize MFC and do call CreateThread?!?! Clarification anyone? HomeNuke ---- "Nuke'd Your Home, Yet?" Run your own PostNuke based web server from home http://www.homenuke.com
-
Might not get into the while until the listen call returns, i.e. something connects. As stated above, might want to fake a connection on 127.0.0.1 to kick the listen off its perch when shutting down.
Checked for that with the debugger was able to start stepping through the while loop. That gave me the impression that I was in there, hopefully the while loop is not split off into it's own thread that runs while listen is tied up :) That would be just my luck... HomeNuke ---- "Nuke'd Your Home, Yet?" Run your own PostNuke based web server from home http://www.homenuke.com
-
Just clarifying the acutual code in the while loop now is:
listen(sListen, 5);
while (1)
[
if (pThreadData->Stop)
break; //Just exit the while loop and let the thread close out
]closesocket(sListen);
WSAcleanup();
return 0;
It is just bare minimum because I'm trying to see why I get the memory leak. I have nothing else in the while loop pertaining to the socket. HomeNuke ---- "Nuke'd Your Home, Yet?" Run your own PostNuke based web server from home http://www.homenuke.com
-
Checked for that with the debugger was able to start stepping through the while loop. That gave me the impression that I was in there, hopefully the while loop is not split off into it's own thread that runs while listen is tied up :) That would be just my luck... HomeNuke ---- "Nuke'd Your Home, Yet?" Run your own PostNuke based web server from home http://www.homenuke.com
-
Ah...that could be the step I'm missing :) I'm not inheriting from CWinThread so to speak, but it is what is returned when you call AfxBeginThread() :) I was told not to call CreateThread from within an MFC function or be forewarned about doing so...I don't even know if that is correct now since I have gone through several source codes that utilize MFC and do call CreateThread?!?! Clarification anyone? HomeNuke ---- "Nuke'd Your Home, Yet?" Run your own PostNuke based web server from home http://www.homenuke.com
Okay, unless you want to save the returning pointer of CWinThread there's little help to call
AfxBeginThreadsince_beginthreadexis all you need. - Yes, you still can change "m_bAutoDelete" to TRUE - Yes, it's better to call_beginthreadexor_beginthreadin MFC but you may still get away with it by callingCreateThread. - Greatest invention : "The Microchip!" -
Okay, unless you want to save the returning pointer of CWinThread there's little help to call
AfxBeginThreadsince_beginthreadexis all you need. - Yes, you still can change "m_bAutoDelete" to TRUE - Yes, it's better to call_beginthreadexor_beginthreadin MFC but you may still get away with it by callingCreateThread. - Greatest invention : "The Microchip!"Ernest thanks for being patient. Yeah all the literature I have on MFC always say use AfxBeginThread, and thanks for elaborating on the different thread calls. I wonder why the PSDK or the many books I HAVE on MFC don't mention those functions?!?! Thanks! HomeNuke ---- "Nuke'd Your Home, Yet?" Run your own PostNuke based web server from home http://www.homenuke.com