TerminateThread function and a class deconstructor

[Kahiko]

Hello i am writing a application that is using winsock. I decided to put all winsock relating functions in one class. Example below

class networking
{
networking
{
WSADATA wsaData;
WSAStartup(MAKEWORD(2,0),&wsaData);
Socket=socket(AF_INET,SOCK_STREAM,IPROTO_TCP);
SockAddr.sin_family=AF_INET;
SockAddr.sin_port=htons(80);
SockAddr.sin_addr.S_un.S_addr=inet_addr("127.0.0.1");
}
~networking
{
CloseSocket(Socket);
WSACleanup();
}

public:

bool Connect()
{
if(connect(Socket,reinterpret_cast<sockaddr*>(&SockAddr),sizeof(SockAddr))==0)
{
return true;
}
else
{
return false;
}
}

}


//So when i type the following inside of a function.

void Function_example()
{
networking network
network.connect();
//Do some stuff inside of a infinite loop
}

And after that the function stops for watever reason the socket is closed and wsacleanup() is called.

//My problem is that i run the function_example() in another thread. And i use //TerminateThread to stop it. Would the deconstructor of networking be called? //Here are some qoutes that made me doubt


cplusplus on classes

The destructor fulfills the opposite functionality. It is automatically called when an object is destroyed, either because its scope of existence has finished (for example, if it was defined as a local object within a function and the function ends) or because it is an object dynamically assigned and it is released using the operator delete.

msdn on TerminateThread()

TerminateThread is used to cause a thread to exit. When this occurs, the target thread has no chance to execute any user-mode code. DLLs attached to the thread are not notified that the thread is terminating. The system frees the thread's initial stack.

Windows Server 2003 and Windows XP/2000: The target thread's initial stack is not freed, causing a resource leak.

TerminateThread is a dangerous function that should only be used in the most extreme cases. You should call TerminateThread only if you know exactly what the target thread is doing, and you control all of the code that the target thread could possibly be running at the time of the termination. For example, TerminateThread can result in the following problems:

If the target thread owns a critical section, the critical section will not be released.
If the target thread is allocating memory from the heap, the heap lock will not be released.
If the target thread is executing certain kernel32 calls when it is terminated, the kernel32 state for the thread's process could be inconsistent.
If the target thread is manipulating the global state of a shared DLL, the state of the DLL could be destroyed, affecting other users of the DLL.


Well i am using winsock but it should get cleaned up neatly if the deconstructor is called. But does it get called at all? Also is there not any nice way of doing this i was thinking about creating a global bool that simply said networkingstate while it is true keep running Function_example once it is false the thread will exit itself and cleanup. But for this i NEED a global variable and i NEED to check it alot of times. Also while a socket is blocking and can not check the sate of networking bool. So this is not really a great solution.

Are there any other ways to do this. I want to say from my main function hey thread you are going to exit and stop using winsock and close that socket!

[webJose]

My guess is NO, and you should NOT use TerminateThread(). If you want to exit the thread, define a manual or autoreset event to signal the thread you want to exit. I assume that any blocking call to the network components can be waited on, meaning you can either wait for the event or the network event.