|
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
|
|
|
|
|
|
Seems like it, unless you're running in .NET 1.0 or 1.1 (unlikely, methinks).
/ravi
|
|
|
|
|
Thanks Ravi,
So, what are the issues of using Abort in relative new version of .Net framework, e.g. 2.0 or later?
regards,
George
|
|
|
|
|
Hi all
simple question but I can't seem to find a specific answer on the web.
I have a VStudio 2005 project with a form and a ball class
I need to have the ball moving across the form
Can someone please point me to a site where how to do this is explained?
Thanks
|
|
|
|
|
|
Thanks Reelix - I think I understand what your code does but I'm still in the dark. (
Basically I have made a class (Ball) that has methods such as move paint get & set position etc.
I also have a form that has a paint method and a loop that changes the position of the ball with the aim being the ball moves across the screen.
It doesn't.
I read somewhere that you had to override the onpaint() method on the form so I had a go at that but that doesn't work either.
It seems that this should just be a 5 minute task but it has already taken up a day and a half.
I'm beginning to hate programming all over again !!
|
|
|
|