#10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <<loop>>) -------------------------------------+------------------------------------- Reporter: exio4 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): We need Simon Marlow's advice here. What you say does seem plausible: * With lazy blackholing, a single-entry thunk will never be black-holed. Lazy black-holing only black-holes thunks with an update frame on the stack, and single-entry thunks do not push an update frame. So that could explain why `-feager-blackholing` is required. * Rather to my surprise, a single-entry thunk is black-holed. I can't see any good reason why this happens. Look at `StgCmmClosure.blackHoleOnEntry`. * Re comment:22 we need Simon to say. It would be pretty bad if every module had to be compiled consistently. However I note that the comment in `Scav.c` is in code that messes with update frames, and so single-entry thunks probably don't matter. Even if all this is right, we still don't know why we get `<<loop>>`. I'm assuming that this means we have entered a black hole, ''that is under evaluation by this thread''; but suddenly I'm not sure. (For a black hole being evaluated by another thread, we'd block.) I suggest you try making `blackHoleOnEntry` return False for single-entry thunks. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10414#comment:23 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler