CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 3 of 3

Thread: Killing threads

  1. #1
    Join Date
    Apr 1999
    Posts
    50

    Killing threads

    We develop a finite element application with a facility for users to abort analysis while it is running. Because the analysis code is not structured to poll a stop flag regularly and needs to clean up which TerminateThread() does not do we wrote our own kill routine:

    Code:
    void KillThread(HANDLE hThread)
    {
    	CSingleLock cSLock(KillThreadCrit());
    	_lock(_HEAP_LOCK);
    	_lock(_TIME_LOCK);
    	AfxLockGlobals(CRIT_LOCKSHARED);
    
    	// kill thread
    	if(::SuspendThread(hThread) != 0xffffffff)
    	{
    		// As you can't signal a thread directly, change the thread's
    		// program counter to trigger an exception.
    		CONTEXT cContext;
    		cContext.ContextFlags = CONTEXT_CONTROL;
    		::GetThreadContext(hThread, &cContext);
    
    		// Set the program counter - this depends on the processor and
    		// may be more complicated on some architectures.
    		// Could pass a pointer to an exception raising routine.
    		*--reinterpret_cast<DWORD*&>(cContext.Esp) = cContext.Eip;
    		cContext.Eip = reinterpret_cast<DWORD>(RaiseThreadException);
    		::SetThreadContext(hThread, &cContext);
    
    		::ResumeThread(hThread);	// to its doom
    	}
    
    	AfxUnlockGlobals(CRIT_LOCKSHARED);
    	_unlock(_TIME_LOCK);
    	_unlock(_HEAP_LOCK);
    }
    Although we have used this code for several years it can be fragile and there have recently been reports of the program hanging at calls to WaitForSingleObject() immediately followin the call to this routine.

    Is there a better way to do this? In particular is there a better way to unwind another thread’s stack?

  2. #2
    Join Date
    Jun 2002
    Location
    Cambridge, UK
    Posts
    28

    Re: Killing threads

    I am not sure I completely understand how 'throw'ing while your thread which may be preparing to make a kernel call really differs much from just terminating it in terms of safety and releasing all mutexes properly.
    The only portable solution for the analysis routine seem to make it out-of-process. Which will depend on application complexity, but then again the application complexity appears to be very high because you have not opted for a state-machine or tried putting wrappers around any calls that can take a long time to complete. A brief hunt into the land of the CONTEXT structure reveals only portability problems and more danger.

    Perhaps if the worker-thread was made responsible for keeping a collection of all objects it opens, (a garbage can if you like) so that the "killer" can come along afterwards and clean them all up if ever it has to do any dirty-work.
    (edit)
    Looking again, I am imagining the exception is getting-handled by someone else's handler, hence the problem?
    Last edited by Conrad Braam; October 11th, 2007 at 01:19 PM.

  3. #3
    Join Date
    Apr 1999
    Posts
    50

    Re: Killing threads

    Quote Originally Posted by Conrad Braam
    I am not sure I completely understand how 'throw'ing while your thread which may be preparing to make a kernel call really differs much from just terminating it in terms of safety and releasing all mutexes properly.
    We protect some points from interruption with critical sections including the rich text window the analysis thread logs to. Maybe we don’t protect enough.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured