Understanding behavior of BlockedIndefinitelyOnMVar exception

Brandon Simmons brandon.m.simmons at gmail.com
Mon Jul 25 22:24:39 CEST 2011

On Sun, Jul 24, 2011 at 10:07 PM, Edward Z. Yang <ezyang at mit.edu> wrote:
> Excerpts from Felipe Almeida Lessa's message of Sun Jul 24 22:02:36 -0400 2011:
>> Does anything change if you somehow force a GC sometime after "good2"?
>>  Perhaps with some calculation generating garbage, perhaps with
>> performGC.  IIRC, the runtime detects BlockedIndefinitelyOnMVar on GC.
>>  But I'm probably wrong =).
> That's correct.
>   resurrectThreads is called after garbage collection on the list of
>   threads found to be garbage.  Each of these threads will be woken
>   up and sent a signal: BlockedOnDeadMVar if the thread was blocked
>   on an MVar, or NonTermination if the thread was blocked on a Black
>   Hole.
> Cheers,
> Edward

Thanks, Edward. I'm going to take a look at the GHC source and see if
I can grok any of it. Any comment on whether it is correct behavior to
have the exception raised in all the threads attempting a readMVar at
once (if that's actually what's happening), even though an exception
handler will fill the MVar for subsequent threads?

I think I'm not totally clear on what qualifies as "indefinitely"

Thanks again,

More information about the Glasgow-haskell-users mailing list