C / C++ / MFC

25-Jan-02 6:00

I have been trying to terminate a thread I started in my application. I am writing a server application and have spun a seperate thread off for the server, that in turns spawns another thread when a client connects, and I am using Winsock 2.2. During the listen portion of the server thread I put it in a while loop more specifically:

while(1)
{
   //Code to listen and spawn thread goes here
}

However, I get a memory leak when I quit the application, since it is in a while loop the thread can not properly terminate. I have tried several methods in order to get it to terminate. Here is what I have tried:

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.

Tried using a loop in the close function to make sure that the thread has stopped by checking the return value of ::GetExitCodeThread and making sure it doesn't return STILL_ACTIVE--No success

Current thoughts:

Even though this is a worker thread as defined by MFC I'm thinking of turning it into a UI thread so I can use PostQuitMessage and send a user defined message to thread to terminate.

Any suggestions to resolving this matter? Thanks in advance for any help.

HomeNuke
----
"Nuke'd Your Home, Yet?"
Run your own PostNuke based web server from home
http://www.homenuke.com

25-Jan-02 6:31

Sounds like you're on the right track - just mumbling here...

Got a Sleep(...) in you're thread loop?

Check for slightly more than STILL_ACTIVE in your shutdown?

do
{
    ::Sleep(100);
    bResult = ::GetExitCodeThread(m_pMyThread->m_hThread, &dwExitCode);
} while (dwExitCode == STILL_ACTIVE && bResult);

Do you have an accept socket blocking? Kick it off with a localhost connect.

...end mumble.

pba_25-Jan-02 6:47

pba_

25-Jan-02 6:47

Wait for the child thread before leaving the main thread - if you do that in a thread with UI don't forget to pump messages :

.......
child thread signal exit
.....
//wait for child
while( WAIT_OBJECT_0 != ::WaitForSingleObject( hThreadChild, 10))
{
MSG msg;
while( ::PeekMessage( &msg, NULL, 0, 0, PM_REMOVE))
{
TranslateMessage( &msg);
DispatchMessage( &msg);
}
}

Ernest Laurentin25-Jan-02 6:50

25-Jan-02 6:50

- If your working thread has called accept(socket,..) and is currently
waiting for a connection, you may close the socket (closesocket(socket)
to force it to return.
- In OnClose() function, you need to call closesocket(m_ThreadParam->socket)
- You may want to add this new member "socket" in your ThreadParam struct
Good luck!

- Greatest invention : "The Microchip!"

HomeNuke25-Jan-02 7:04

25-Jan-02 7:04

Thanks to all of you. I will try this when I get home. I just hate when you are running your app in debug mode and as soon as the application stops you get a "Memory leak detected" in your debug window Frown | :(

Especially since this is a server application I don't want to many memory leaks going on, throught the course of the day it may kill the server, even though at this time the app only generates one thread for the server function, but it generates multiple threads for each connection...

Thank you, and I will try all of your suggestions when I get home. However, if anyone has more advice I'm am still open to hearing them. Big Grin | :-D

HomeNuke
----
"Nuke'd Your Home, Yet?"
Run your own PostNuke based web server from home
http://www.homenuke.com

25-Jan-02 7:01

"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."

Why doesn't it work? Most likely your code to check the bool value was not executed because the worker thread was blocking (waiting for other things). There is no way to terminate a worker thread within itself effectively. If you have the thread handle, you can call TerminateThread from outside, but there are warnings against using TerminateThread (see MSDN).

User interface thread is different because it has a message pump, so it can process the quit message. But it changes the way your program works.

Matt Gullett25-Jan-02 7:42

Matt Gullett

25-Jan-02 7:42

"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

HomeNuke25-Jan-02 7:51

25-Jan-02 7:51

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

Ernest Laurentin25-Jan-02 8:47

25-Jan-02 8:47

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" Blush | :O

- Greatest invention : "The Microchip!"

HomeNuke25-Jan-02 8:52

25-Jan-02 8:52

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 Smile | :)

**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

Ernest Laurentin25-Jan-02 9:25

25-Jan-02 9:25

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!"

HomeNuke25-Jan-02 9:28

25-Jan-02 9:28

Ah...that could be the step I'm missing Smile | :)

I'm not inheriting from CWinThread so to speak, but it is what is returned when you call AfxBeginThread() Smile | :)

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

Ernest Laurentin25-Jan-02 10:29

25-Jan-02 10:29

Okay, unless you want to save the returning pointer of CWinThread
there's little help to call AfxBeginThread since _beginthreadex
is all you need.
- Yes, you still can change "m_bAutoDelete" to TRUE
- Yes, it's better to call _beginthreadex or _beginthread in MFC
but you may still get away with it by calling CreateThread.

- Greatest invention : "The Microchip!"

HomeNuke25-Jan-02 11:28

25-Jan-02 11:28

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

25-Jan-02 9:43

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.

HomeNuke25-Jan-02 9:42

25-Jan-02 9:42

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 Smile | :)

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