Understanding behavior of BlockedIndefinitelyOnMVar exception
brandon.m.simmons at gmail.com
Mon Jul 25 22:05:39 CEST 2011
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
main2 = do
lock <- newMVar ()
forkIO $ lockPrint "good1" lock
forkIO $ badLockPrint "bad" lock
-- these both raise blocked indefinitely exception
forkIO $ lockPrint "good2" lock
forkIO $ lockPrint "good3" lock
Perhaps laziness is confusing the issue as well?
Thanks and sorry for the delayed response,
More information about the Glasgow-haskell-users