[Haskell-cafe] Re: A GHC error message puzzle
Simon Marlow
marlowsd at gmail.com
Mon Aug 16 06:14:57 EDT 2010
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
More information about the Haskell-Cafe
mailing list