Thread.Abort fixed for finally blocks?
In .NET Framework 1.0 & 1.1, calling Thread.Abort on another thread could abort that thread while executing the "finally" part of a try/catch/finally block. That was rather nasty because it could lead to criticial resources not being released by the aborted thread.
Now I see in the July CTP docs that this situation is documented as a possibility for 1.0 & 1.1 only. May be assume that this has been fixed in 2.0, and that all finally blocks will properly execute in the aborted thread, no matter when the ThreadAbortException happens?
Another question: ThreadAbortException can still happen in a catch block and abort the current exception processing, correct?
It's a great analysis of finalization, but that's unrelated to my question. I was asking about "finally" blocks, as in try/catch/finally, not about finalization, as in C# "destructors".
David, I've read the whole article when it was first posted, recently read it again, and I've also read up on the new SafeHandle feature. This has nothing to do with my question.
The article is about finalization, i.e. the execution of finalizers.
I'm asking about the execution of "finally" blocks in the presence of a ThreadAbortException.
These are two completely different, completely unrelated features...
In Whidbey by default we will delay thread abort injection over all exception handling blocks (finally, catch, and fault).
We've also added the concept of "Rude aborts" in Whidbey which are completely uncatchable by everything except for Constrained Execution Regions. You'll only see rude aborts in a hosted environment like SQL Server 2005 where escalation policy is enabled (for example if your finally takes too long to run SQL will escalate it to a rude abort unless it's a CER finally). For Win32 programmers this is the near equivalent of TerminateThread.
