Remotely terminating a thread?

[MrDoomMaster]

Is there a way to terminate a thread from another thread? For example, lets say you have a thread that checks an event every iteration to see if it needs to call _endthread(). Well, lets say you're using a blocking function in this thread, such as winsock's 'accept()' function. There will never be a way to terminate this function later because accept() never returns! So this means you need to force a hard shutdown of the thread from another thread. This isn't the safest way, but it's better than leaving the thread running and causing memory leaks!!!!

Thanks!

Also, why does WaitForSingleObject() cause a memory read error when I use it in a thread created by _beginthreadex()?

[Andreas Masur]

[ Moved thread ]

[Andreas Masur]

Is there a way to terminate a thread from another thread? For example, lets say you have a thread that checks an event every iteration to see if it needs to call _endthread(). Well, lets say you're using a blocking function in this thread, such as winsock's 'accept()' function. There will never be a way to terminate this function later because accept() never returns! So this means you need to force a hard shutdown of the thread from another thread. This isn't the safest way, but it's better than leaving the thread running and causing memory leaks!!!!
Well...this is always a tricky problem...of course the main advice is not to use blocking functions within a thread... :cool:

I agree though that this is good theory but not practice...as for sockets there are several workarounds...as for example: Assuming that you monitor your status somehow with 'select()', add a 'shutdown' socket to the list of sockets. At the time you want to shutdown, simply close this 'shutdown' socket and 'select' will immediately return...

Also, why does WaitForSingleObject() cause a memory read error when I use it in a thread created by _beginthreadex()?
Well..without seeing the code...make sure the handle is valid...

[MrDoomMaster]

Well, I'm not using select to monitor my status... so that poses a problem.

All it is, a worker thread that does something like this:


void WorkerThread(void)
{
while(true)
{
accept(....);
}
}


This isn't supposed to compile right, I just kind of jotted it down. This is supposed to give you a basic idea of how the thread is structured, and how the blocking function is being called. Of course, included in the worker thread are event checks, to see when it needs to close. But remember, accept() does not return until a connection has been detected on the listening socket!

Any other ideas? I really wish there was a function I could call to close it externally! Isn't there some rough a** function that faults the process? Completely destroys the thread? Almost like a virus? lol... Would it be possible to create such a function? I imagine if I created it, it would do a lot of low level stuff to get the thread closed and the memory cleaned up... But if _endthreadex() can do it internally, that is a small hint that it can be done externally...

Thanks!

[Arjay]

[QUOTE=MrDoomMaster]But remember, accept() does not return until a connection has been detected on the listening socket!
QUOTE]
First of all, a disclaimer - I don't really know anything about sockets. I did read that a socket can be either blocking or non-blocking. It sounds to me that your usage is currently the blocking variety.

Is it possible to change it to the non-blocking type (so that it returns immediately with either a valid socket or INVALID_SOCKET)?

Arjay

[Mathew Joy]

But remember, accept() does not return until a connection has been detected on the listening socket! Not exactly! accept() also returns in the case of an error; that's where the solution lies. Close the socket that is listening from anywhere and your accept() unblocks and return with an error, probably WSAENOTSOCK. On getting this error - maybe you could also use an event to signal that the system/app is going to shutdown - you can safely exit the thread. You can make sure the thread is exited by using the WaitForSingleObject(threadhandle, dwtime), maybe in the main thread.

Using threads is a solution for the blocking problem, and there won't be any problem or any issues if you design it properly - ofcourse other than the issue of scalabality.