|
George_George wrote: Can we rely on finally block and exception handler for ThreadAbortException?
A using block is the best way to ensure that objects are disposed. A try...finally works just as fine, assuming that you implement it correctly. The ThreadAbortException is sure to occur if the thread is aborted, but as it can happen anywhere in the code, it's a lot trickier to implement correctly.
George_George wrote: Seems the timeout issue for Finalizer (Finalizer can not execute longer than some amount of time, as your referred article describes) only happens when AppDomain shuts down. If the AppDomain is still running, there should not be timeout issue?
There could be, if one finaliser doesn't return. I'm not sure how the finilising thread handles this, but either it locks up, or it times out that specific finalisation after a while. Even if it has a timeout for every finalisation, it migh be busy for a very long time if there are a lot of instances of the same class, where the finaliser doesn't work.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Cool, Guffa!
I am just curious that why there is no documents which we could find that expected finally blocks and exception handler block are ensured to be executed during ThreadAbortException?
regards,
George
|
|
|
|
|
There is no specific documentation about this, because it's not handled any different than in any other code.
The only thing that is special is that the ThreadAbortException is thrown whenever the thread is aborted, and (AFAIK) that the exception doesn't cause a ThreadException in the application, if the thread doesn't catch it. Other than that, the situation is handled just as with any other exception.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Thanks Guffa,
Suppose I have ThreadAbortException in a worker thread, the main thread could only catch it by using AppDomain.CurrentDomain.UnhandledException?
regards,
George
|
|
|
|
|
George_George wrote: Suppose I have ThreadAbortException in a worker thread, the main thread could only catch it by using AppDomain.CurrentDomain.UnhandledException?
Yes, that would be the only way of catching an exception from outside the thread. However, I don't think that a ThreadAbortException exception will cause that event to be triggered, but I can't find any documentation right now that either confirms or contradicts this.
A couple of clarifications/additions that I found while reading about the ThreadAbortException:
There is one more thing that is special about the ThreadAbortExcpetion; it will automatically be rethrown even when caught. So, it will trigger any matching catch all the way up the stack, unless Thread.ResetAbort is called to stop it from being rethrown.
The ThreadAbortException exception can be used by the thread to catch when the application is aborting the thread, but if a background thread is aborted because the application is ending, the exception will not be thrown.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Thanks Guffa,
1.
Guffa wrote: Yes, that would be the only way of catching an exception from outside the thread. However, I don't think that a ThreadAbortException exception will cause that event to be triggered, but I can't find any documentation right now that either confirms or contradicts this.
I have verified you are correct. Here is my code. Could you review whether my code is correct please?
using System;
using System.Threading;
using System.IO;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace ConsoleApplication2
{
class Program
{
static void ThreadProc()
{
Console.WriteLine("Begin sleeping ");
Thread.Sleep(5000);
Console.WriteLine("End sleeping ");
}
static void Foo(object sender, UnhandledExceptionEventArgs e)
{
Console.WriteLine("I am here ");
}
static void Main(string[] args)
{
AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(Foo);
Thread t = new Thread(Program.ThreadProc);
t.Start();
t.Abort();
return;
}
}
}
2.
Guffa wrote: but if a background thread is aborted because the application is ending, the exception will not be thrown.
Confused. You mean the ThreadAbortException will not be re-throw if it is caught?
regards,
George
|
|
|
|
|
George_George wrote: I have verified you are correct. Here is my code. Could you review whether my code is correct please?
Yes, that is correct as far as I can see.
George_George wrote: Confused. You mean the ThreadAbortException will not be re-throw if it is caught?
No, I mean that the ThreadAbortException will not be thrown at all. The background threads will just be stopped.
From the documentation of the Thead.IsBackground property:
"Once all foreground threads belonging to a process have terminated, the common language runtime ends the process. Any remaining background threads are stopped and do not complete."
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Thanks Guffa,
Guffa wrote: No, I mean that the ThreadAbortException will not be thrown at all.
I have verified that ThreadAbortException will be thrown, here is my code. Please review whether my code is correct.
In my test in VS 2008, the lines, will be executed, means ThreadAbortException will be thrown,
catch (Exception ex)
{
Console.WriteLine(ex.ToString());
}
using System;
using System.Threading;
using System.IO;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace ConsoleApplication2
{
class Program
{
static void ThreadProc()
{
try
{
Console.WriteLine("Begin sleeping ");
Thread.Sleep(5000);
Console.WriteLine("End sleeping ");
}
catch (Exception ex)
{
Console.WriteLine(ex.ToString());
}
}
static void Foo(object sender, UnhandledExceptionEventArgs e)
{
Console.WriteLine("I am here ");
}
static void Main(string[] args)
{
AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(Foo);
Thread t = new Thread(Program.ThreadProc);
t.IsBackground = true;
t.Start();
Thread.Sleep(1000);
t.Abort();
Console.WriteLine("I am there ");
return;
}
}
}
regards,
George
|
|
|
|
|
Yes, of course it will be thrown if you abort the thread.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Thanks Guffa,
This is what you mentioned before.
--------------------
No, I mean that the ThreadAbortException will not be thrown at all. The background threads will just be stopped.
--------------------
I do not think there is any differences dealing with Thread.Abort a background thread and a normal thread. If you think there are any differences, could you post your code or describe your ideas in more details please (so that I can write some test code to learn from you)?
regards,
George
|
|
|
|
|
George_George wrote: I do not think there is any differences dealing with Thread.Abort a background thread and a normal thread.
That's correct.
If you look at the quote in context, you will see that I was talking about what happens to the threads when the application ends.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Thanks Guffa,
Question answered.
regards,
George
|
|
|
|
|
Hello everyone,
About using Abort or Interrrupt to stop a thread, I have two questions.
1. What are the pros and cons about Abort v.s. Interrupt?
2. If I program a background thread, compared with normal thread, will there be any special points to take care of (e.g. code in different) if the thread is stopped with Abort (or Interrupt)?
thanks in advance,
George
|
|
|
|
|
An excellent tutorial here[^].
SkyWalker
|
|
|
|
|
Thanks Mircea,
Actually, this is the question when I read the famous tutorial.
But no direct answer from the tutorial. Do you have any ideas?
regards,
George
|
|
|
|
|
A blocked thread can be released prematurely in one of two ways:
- through Thread.Interrupt;
- through Thread.Abort.
1) This will happen through the activity of another thread.
Interrupting a thread only releases it from its current/next) wait.
It doesn't cause the thread to end (unless the ThreadInterruptedException is unhandled).
If Interrupt is called on a thread that’s not blocked, the thread continues executing until it next blocks. At that point a ThreadInterruptedException is thrown.
Interrupting a thread arbitrarily is dangerous as the framework or some third-party methods in the calling stack could unexpectedly receive the interrupt rather than your intended code. All it would take is for the thread to block briefly on a simple lock or synchronization resource, and any pending interruption would kick in. If the method wasn't designed to be interrupted (with appropriate cleanup code in finally blocks) some objects may be left in an unusable state, or there may be resources incompletely released.
2) A blocked thread can also be released via its Abort method. This would lead to a similar effect like in the case of calling Interrupt , excepting that a ThreadAbortException is thrown instead of a ThreadInterruptedException . And one more thing here: the exception will be re-thrown at the end of the catch block (in an attempt to terminate the thread for ever) unless Thread.ResetAbort is called within the catch block.
The main difference between Interrupt and Abort concerns what happens when each of them is called on a thread that is not blocked. While Interrupt waits until the thread next blocks before doing anything, Abort throws an exception on the thread right where it's executing.
SkyWalker
|
|
|
|
|
Thanks Mircea,
Two more questions,
1. When using Interrupt method, we need to consider whether thread is in wait status. I am wondering if,
- the thread is executing and waiting on lock (someobject), e.g. blocked on lock statement or Monitor statement;
- or trying to acquire (but not acquired yet) a readwrite lock;
Will the thread be interrupted in the above two situations when we call Interrupt?
2.
Is it ensured the Finally block for ThreadInterruptedException (for Thread.Interrupt called), and Finally block for ThreadAbortException (for Thread.Abort called) be ensured to be executed? If yes, I can rely on resource relase method there to ensure no resource leak.
regards,
George
|
|
|
|
|
1) A thread blocked while awaiting a lock has a ThreadState of WaitSleepJoin. A thread blocked in this state can be forcibly released by another thread calling its Interrupt or Abort method.
2) The finally block gets always executed.
SkyWalker
|
|
|
|
|
Thanks Mircea,
I heard there are some issues of using Thread.Abort. So, what are the issues of using Abort in relative new version of .Net framework, e.g. 2.0 or later? If all expected finally blocks are executed, it should be fine, right?
regards,
George
|
|
|
|
|
Well, long story short, "Thread.Abort is a sign of a poorly designed program" as Peter Ritchie says. Go have a look at his opinions[^].
SkyWalker
|
|
|
|
|
Thanks Mircea,
Good reference. But after reading it, I do not think it is bad API. Here is what I find valuable from the reference you recommended,
"it does cause all finally blocks that it knows about to execute before your thread is stopped and won't terminate your thread while it's in a catch or finally block."
I think we can free resource in finally block. Why do you think using Thread.Abort is bad?
regards,
George
|
|
|
|
|
I did not say it is bad. I said it is poor programming.
SkyWalker
modified on Friday, April 25, 2008 5:01 AM
|
|
|
|
|
Thanks Mircea,
regards,
George
|
|
|
|
|
George_George wrote: About using Abort or Interrrupt to stop a thread,
See Jon's article on this subject here[^].
/ravi
|
|
|
|
|
|