Understanding behavior of BlockedIndefinitelyOnMVar exception

[Brandon Simmons]

On Sun, Jul 24, 2011 at 10:02 PM, Felipe Almeida Lessa
<felipe.lessa at gmail.com> wrote:
> On Sun, Jul 24, 2011 at 7:56 PM, Brandon Simmons
> <brandon.m.simmons at gmail.com> wrote:
>> What I think I've learned here is that the BlockedIndefinitelyOnMVar
>> exception is raised in all the blocked threads "at once" as it were.
>> That despite the fact that the handler code in 'lockPrint' restores
>> the lock for successive threads.
>>
>> This would also seem to imply that putMVar's in an exception handler
>> don't stop the runtime from raising the BlockedIndefinitelyOnMVar. But
>> that doesn't really seem right.
>
> 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 =).

Here is a variation that calls 'performGC' after the first thread is
forked. It prints the exception simultaneously right before  the last
'threadDelay':

main2 = do
    lock <- newMVar ()
    forkIO $ lockPrint "good1" lock

    threadDelay 1000000
    forkIO $ badLockPrint "bad" lock

    -- these both raise blocked indefinitely exception
    threadDelay 1000000
    forkIO $ lockPrint "good2" lock
    performGC
    threadDelay 1000000
    forkIO $ lockPrint "good3" lock

    threadDelay 1000000

Perhaps laziness is confusing the issue as well?

Thanks and sorry for the delayed response,
Brandon Simmons



>
> Cheers,
>
> --
> Felipe.
>