[GHC] #10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <<loop>>)

[GHC]

#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