On 14/08/2010 22:29, Yitzchak Gale wrote:
Lennart Augustsson wrote:
So it's a bug in the garbage collector. It's closing a handle that clearly is still reachable, otherwise this would not have happened.
Simon Marlow wrote:
The handle is in fact not reachable from the roots, because the thread that points to it is also not reachable.
I think I agree with Lennart here. A thread with an active exception handler is not permanently unreachable, only temporarily unreachable, unless we know that it is impossible for any exception to be thrown at it that it is capable of catching. In this case, the handler can catch a NonTermination, so it is not unreachable. A keyboard interrupt is another possibility.
You could also argue that a thread should not be considered deadlocked if a finalizer can wake it up - the problem is that these two requirements are contradictory. It's hard for me to tell which is more important, though certainly the evidence from this thread has swung things towards flipping the current behaviour. I wonder whether anyone is relying on the way things currently work, e.g. if you had a thread that waits for finalizers to run, then it would receive a BlockedIndefinitely exception under the changed semantics. Cheers, Simon
If we know that things are really stuck it could still be helpful for us to throw the NonTermination, but that doesn't mean that the handle should be considered unreachable at the time.
It is very important to do the best we can to allow people's exception handlers to run successfully, especially in a bracket. That is a much higher priority than protecting people from hanging their app when they write poor exception handlers. By finalizing the handle, you are significantly lowering the chance of exception handlers being able to do a proper job.
I do agree, though, that hClose should be less finicky about finalized handles, which would solve the problem in this particular case.
Thanks, Yitz