See inline.
"Manfred" <ml@agileutilities.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...
| Other wrote:
| "This is a bad suggestion, you should never call Thread.Abort from user
| code."
| "Calling Thread.Abort is a very BAD BAD BAD BAD (did I say BAD) idea!"
|
| I disagree with these statements.
No problem, allow me to disagree with yours ;-)
Calling Thread.Abort() is perfectly
| acceptable. Let me explain my point of view.
|
Only if you call it on your own thread, or if you are going to unload the AD
anyway. The situation in V2 is not that bad, as some changes have been made
to the CLR to give you a chance to recover from asynchronous thread aborts,
but it's still hard to get it right.
| An application with one thread handling the UI and a different thread,
| the worker thread, executing some lengthy operation is a perfectly
| acceptable solution. That way the UI stays responsive. There are
| obviously other cases where starting and terminating threads is the
| best (and sometimes the only) design choice, e.g. how do you cancel a
| blocking call? Terminating the process?
|
Thread.Abort cannot cancel a blocking call, it can only terminate a thread
that is executing JIT compiled code, a thread that executes or blocks in
unmanaged code cannot be terminated, the CLR has no control over threads
that are transitioning into unmanaged code.
| Polling a flag is certainly not an option. It is not deterministic
So is Thread.Abort see the docs.
<The thread is not guaranteed to abort immediately, or at all...>
in
| particular if the code in the thread does not poll the flag, e.g. when
| a blocking call is made. (How do you time out when you try to get
| exclusive access to a file?)
What do you mean by that? A thread that can open a file exclusively won't
block when performing IO, even if it could block waiting for IO completion,
it's blocked in unmanaged code, so Thread.Abort won't succeed either. A
program that tries to open a file exclusively will throw if it can't open
the file.
|
| There is, however, a suggested coding technique for properly shutting
| down a thread when it is being terminated using Thread.Abort(). The
| runtime throws a ThreadAbortException which should be handled in the
| thread. See documentation at
|
http://msdn2.microsoft.com/en-us/library/cyayh29d.aspx.
|
All I can say is that this part of the docs is misleading at best!
Please read these to understand why:
http://www.interact-sw.co.uk/iangblo...2/cancellation http://weblogs.asp.net/justin_rogers.../02/66537.aspx
or from MSFT folks on the CLR team...
http://blogs.msdn.com/cbrumme/archiv.../17/51361.aspx http://www.bluebytesoftware.com/blog...c-7847d98f1641
Willy.
