#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 michaelt): Sorry, I'm spamming the trac a bit. Notice that in the ultra-simplified module, now attached properly, the wrapping with `Lift` that `parallel` uses for `rparWith` is no where to be found. If I wrap stuff in my `ill_sequenced` with `Lift`, I can't get the effect. If though, that use of `Lift` in the definition of `rparWith` is required by whatever is going on with `spark#` and some of these other opaque-to-me primitives, then there is a question whether it is used enough: the original program is doing an end-run around this. It is presumably obviously undesirable, but if in rbarton's par.hs I complicate the definition of `rpar` , which is {{{#!hs rpar :: a -> Eval a rpar x = Eval $ \s -> spark# x s }}} and use instead something like {{{#!hs rpar :: a -> Eval a rpar x = Eval $ \s -> case y of Eval f -> case f s of (# s1 , l #) -> case l of Lift w -> (# s1 , w #) where y = Eval $ \s -> spark# (Lift x) s }}} then it seems all is well again. That probably destroys all the desired effects; but if it doesn't, then the problem may just be that the library is letting the user get too close to `spark#` which is practically naked in `rpar`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10414#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler