#10793: Incorrect blocked on MVar detection -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: wontfix | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonmar): Well, thinking about it a bit more, in this case it would be possible to do something differently. We have * a main thread, blocked on an MVar * a child thread, in an infinite loop * the MVar, reachable from both threads. All of these things are unreachable from the roots, so we definitely can't make progress without throwing an exception. Normally we throw exceptions to all the deadlocked threads in this case, because it's the only deterministic thing we can do. (picking a thread randomly to receive the exception doesn't seem good). We could refine it slightly so that if there are both NonTermination exceptions and BlockedIndefinitelyOnMVar exceptions, we only throw the NonTermination exceptions. We know that waking up the BlockedIndefinitelyOnMVar threads can't unblock the NonTermination threads, but the reverse might be true. That wouldn't change the more common case of this, which is where both threads are blocked on MVars: {{{ main = do v <- newEmptyMVar v2 <- newEmptyMVar forkFinally (takeMVar v2) (putMVar v) print =<< takeMVar v }}} here we'd still get both exceptions at the same time. So I'm not sure how I feel about doing something different for `NonTermination`, possibly making the situation more complicated. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10793#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler