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?

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.
:eek:
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?

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.