|
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 !!
|
|
|
|
|
You should override OnPaint yes, but you should also probably call base.OnPaint() inside it as well.
Anyways, if you have a loop, like
while(loop)
{
}
Its going to run the loop, then draw the 'final frame' as it where.
What you probably want to do (if your not already), is to change the position either in the OnPaint method itself, or in a timer (recommended).
My current favourite word is: Bacon!
-SK Genius
|
|
|
|
|
Why override OnPaint?
Just add it TO OnPaint!
For those who havn't seen my example, it's a yellow block that goes to wherever you click.
You can execute the EXE from INSIDE the .rar file!
Don't know what's so hard about that :p
It shows everything... Eeeevveeryytthing :p
(Including how to stop OnPaint refreshing flickering )
- Reelix
|
|
|
|
|
Since your probably doing all of the drawing to the screen yourself, you should probably use the override, using the event is kinda like this:
override OnPaint
{
Draw form
myPaint();
}
myPaint()
{
Draw over the form anyway
}
You could also override the OnPaintBackground (i think its called) to do nothing, thus reducing any wasted drawing further.
My current favourite word is: Bacon!
-SK Genius
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
