koobas.hobune.stream
finally is not executed when calling Thread.Abort
Does anyone know a reason why finally statement wouldn't be executed when calling Thread.Abort? I have thread function like this:
void ThreadFunc()
{
try
{
int counter = 0;
while (true)
{
Debug.Log ("Waiting" + counter);
Thread.Sleep(100);
++counter;
}
Debug.Log("Success.");
}
catch(ThreadAbortException ex)
{
Debug.LogWarning("Cancelled: " + ex);
}
catch(System.Exception ex)
{
Debug.LogError("Error: " + ex);
}
finally
{
Debug.Log("Finally");
}
}
I terminate this thread using Thread.Abort. All I see in output is a bunch of Waiting, but no other lines. My main thread keeps running after calling Thread.Abort (i.e. child thread has enough time to complete).
This happens on Windows Editor. On Mac Editor it works fine. On iOS I get this behavior, but it seems to depend on device/iOS version or XCode version (I haven't figured out yet). On Windows it happens every time.
BTW: on iOS it crashes if I put another try {} catch {} into finally statement.
Is anyone aware why this is happening? It seems to be quite different from what the documentation of Thread.Abort and ThreadAbortException says.
In my testing it appears that (a) none of Thread.Abort, Thread.Interrupt, and Thread.Suspend do anything unless the thread being interrupted calls Thread.Sleep, and (b) even if the thread does sleep, it does not get a chance to catch a ThreadAbortException or even run a finally block. Thread.Interrupt does result in a ThreadInterruptException, but only after the thread sleeps. Seems like multiple bugs, probably because of the old / custom version of $$anonymous$$ono that Unity is using.
StackOverflow gave quite precise answer:
Mono does not support Constrained Execution Regions and does not fully support catch/finally when Thread.Abort is called.
There is a bug about this.
You might want to take a look at this and turn away from Abort. Threads should never be aborted from outside and if you look through the answers you will see that Abort isn't very reliable.
Well, the documentation of Thread.Abort doesn't hint anything that it should not be used. And I have no problem with complicated behavior of Abort and ThreadAbortException as long as it follows some specific documentation. At the moment behavior seems to vary from platform to platform.
I haven't seen any good alternatives for Thread.Abort which doesn't make your code messy and can actually halt operation which are happening not in your code. And I'm taking about real world thread implementation which makes N connections to the net and $$anonymous$$ loops in different places.
Have you actually read the entire remarks section of Thread.Abort?
The thread is not guaranteed to abort immediately, or at all
This method is actually called when your program exits. The documentation just explains the bare functionality but don't suggest when it might be used.
You might also want to read the answer of Eric Lippert (in case you don't know him, he's one of the guys who wrote the C# compiler at $$anonymous$$S).
This is going off topic. $$anonymous$$y question is why neither catch(ThreadAbortException) nor finally are hit. None of the links explain why finally is not executed. They all talk that you're not guaranteed that thread will ter$$anonymous$$ate, and they imply that if thread is ter$$anonymous$$ated, then finally is called (i.e. the behavior should be according to the documentation). But that's not what I'm getting.
I can see myself that Thread.Abort is not a reliable thing, but I'm saying that implementation in $$anonymous$$ono doesn't follow behavior that is described in documentation. The situations on StackOverflow can be explained, by documentation or wrong implementation, but not in this case.
Have you read Thread.Abort and ThreadAbortException documentation? The "usually" part is quite well defined. The reason why it says "usually" it is because it depends on user's code - your code might never leave finally clause if you want to. The other case where unmanaged code doesn't return, but in that case the alternative methods do not work.
If you ter$$anonymous$$ate a thread forcefully, then yes - bad things can happen (mostly resources left in unknown state). But if it throws an exception and all finally/using clauses are executed properly, then what's the problem exactly?
