My co-worker is using a third-party .NET library for which we don't have the source code. We're using a ThreadPool to have a lot of threads call into this library, and occasionally one of the threads will just hang forever while the rest of them merrily chug along.
So we want to use the dreaded Thread.Abort
to kill such threads. I've done this before when spinning up my own threads, but I've never used a ThreadPool. If we track the start times of each task like this:
static Dictionary<Thread, DateTime> started = new Dictionary<Thread, DateTime>();
static void DoSomeWork(object foo)
{
lock(started)
started[Thread.CurrentThread] = DateTime.Now;
SomeBuggyLibraryThatMightInfiniteLoopOrSomething.callSomeFunction(doo);
lock(started)
started.Remove(Thread.CurrentThread);
}
then can we lock and iterate over the running threads and call Thread.Abort
to kill them? And if we do, then will we need to add a new thread to the ThreadPool to replace the one that we just killed, or will the ThreadPool handle that for us?
EDIT: I'm very aware of all of the potential problems with Thread.Abort
. I know that it should ideally never be used in production code, and that it doesn't necessarily even stop the thread, and that if you abort a thread while the thread has acquired a lock, then you can hang up other threads, etc. But right now we're on a tight deadline and we have decent reason to believe that in this one particular case, we can call Thread.Abort
without putting the entire process in jeopardy, and we'd like to avoid rewriting this program to eliminate the ThreadPool unless we absolutely have to.
So what I want to know is this: given that we WILL be calling Thread.Abort
on a thread that belongs to a ThreadPool, are there any special problems caused by these being ThreadPool threads, and do we have to manually spin up a new thread to replace the one that got killed or will the ThreadPool do that for us?
See Question&Answers more detail:
os 与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…