
On Sun, Jul 24, 2011 at 10:02 PM, Felipe Almeida Lessa
On Sun, Jul 24, 2011 at 7:56 PM, Brandon Simmons
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.