[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