I've used both thread interrupt and thread abort to exit from a thread and
neither is really suitable. The current problem with ThreadAbort is that it
can interrupt code executing in a finally block (this is supposed to be
fixed in a future release of .net) which is mainly why it may be currently
unsuitable as a general mechanism for forcing a thread to exit. Keep in mind
that the way that threads terminate is when the code returns from the
ThreadStart method; using ThreadAbort or ThreadInterrupt is a mechanism for
interrupting it and trying to force it to return all the back up the call
stack to its origin. Since the thread may have an arbitrary number of stack
frames when the exception is thrown, and since there may be an arbitrary
number of catch handlers in the call stack, you have no way of knowing how
many catch handlers must be traversed for the thread to exit. ThreadAbort
has an advantage over ThreadInterrupt in that the exception will propagate
up the call stack regardless of what is caught, so it will keep going up
until it finally does return (unless someone calls ResetAbort to cancel it).
If you use ThreadInterrupt you will have to rethrow it yourself in order to
achieve similar semantics without the problems caused by a ThreadAbort
interrupting execution in a finally block. ThreadInterrupt isn't a true
interrupt - it doesn't bust into the current execution stream to force the
thread to do something so it may not do what you think it will.
side note: There is a way of using an abort that does not cause the problem
above...if the thread you want to kill issues the abort itself, this
effectively synchronizes it with its own execution path so that it should be
safe.
That being said, neither mechanism is the one I currently prefer. When I
launch a thread I usually have it run in a loop that blocks waiting on
multiple events; when one occurs it wakes up, does it work, and then goes
back to sleep. One of those events is a ManualResetEvent which I use as a
signal to exit the thread. This ensures that everything is synchronized and
nothing vital will get interrupted.
There are other issues with using an abort that are not obvious. One is that
if the thread is currently executing unmanaged then the abort will not
actually be raised until it transitions back into managed code - this can be
an arbitrarily long time.
Make sure that you set all worker threads to background threads to ensure
your app can exit even if the thread is still running. Or use a threadpool
thread.
Dave
TT (Tom Tempelaere) said:
Hi Amit,
Perhaps you did not read my question very well. My question was about
Thread.Interrupt, not about Thread.Abort. And the issue is thread cleanup,
and how to do it gracefully (allowing thread resource cleanup). That is what
I mean by "graceful exit". Perhaps I did not make that clear in my original
post. However ...
I do not wish to call Thread.Abort because it does not guarantee graceful
exit. From my .net book (programming .NET components/O'Reilly) I read the
following:
ThreadAbortException is a special kind of exception: even if the thread
handles the exception in a catch clause, the exception is rethrown
afterwards.
This would force me to write thread cleanup in the exception handler, which is a bad thing IMHO.
The book I refer to, explicitely states that one should rely on other
methods than Thread.Abort to perform graceful exit of a thread. I do not
intend to use Thread.Abort to allow graceful exit. The only time that I
would call Thread.Abort is when I have no other options.
Thanks,
Tom.
----- Amit T wrote: -----
Hi,
You can call the Abort method on the Thread. This will generate the
ThreadAbortException. Catch the exception but do not do anything.
So, your application will not throw any unhandled exception.
----- TT (Tom Tempelaere) wrote: -----
Hi there,
What are the community's opinions/experiences on using
Thread.Interrupt to cancel a thread? By canceling, I mean allowing graceful
exit. Is anyone using this as the mechanism to cancel threads?
Second question.
Calling Thread.Interrupt on a thread will cause a
ThreadInterruptedException to be thrown when the thread is in (or enters)
the WaitSleepJoin state. Suppose that I would execute an sql query in the
thread that takes around 30 seconds to complete. I haven't done any DB
coding in C# yet, so I will give an example in pseudo-code:
string sql = "select * from orders";
connection c = /*get connection*/;
resultset rs = c.executeSQL( sql ); // blocks for 30 sec.
Will the thread enter the WaitSleepJoin state in this case? Or
put another way: does C# use a WaitHandle under the hood when C# API blocks?
