[GHC] #13330: forkIO has inconsistent behavior under optimization

[GHC]

#13330: forkIO has inconsistent behavior under optimization
-------------------------------------+-------------------------------------
        Reporter:  dfeuer            |                Owner:  dfeuer
            Type:  bug               |               Status:  patch
        Priority:  normal            |            Milestone:  8.2.1
       Component:  Core Libraries    |              Version:  8.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  Other             |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  Phab:D3189
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by dfeuer):

 Replying to [comment:4 simonpj]:
 > Strange. The definition of `catch` is just
 > {{{
 > catch act = catchException (lazy act)
 > }}}
 > for reasons extensively documented in #11555.  So `catchException` has
 different, less desirable, and undocumented behaviour.
 >
 > Should move the `lazy` into `catchException`?  So then `catch =
 catchException`.  Do we actually want the distinction?
 >
 > Incidentally, the use of 'lazy' in `catch` is entirely un-documented.
 No `Note` no nothing.  While fixing this ticket it would be good to fix
 that too.  At every least a reference to #11555!

 Yes, I can document the `lazy` in `catch`. The distinction probably
 ''does'' make sense, although it was documented quite incorrectly. The
 situation here is a bit tricky: we are trying to deal with the fact that
 `catch#` evaluates its argument ''eagerly'', but is nevertheless ''non-
 strict'' in that argument. The current approach is to lie a little and
 tell the demand analyzer that `catch#` is strict in its argument.
 `catchException` inherits this lie.

 To avoid getting caught in a lie, and to avoid fragile case-specific
 reasoning, the invariant we must maintain is that `catchException` is
 never called with an undefined argument. When this invariant holds, the
 analysis should end up being pretty much correct:

 1. It's safe to evaluate the argument and/or its dependencies early,
 because it will not fail.

 2. After the `catchException` runs, its argument will be in WHNF.

 An alternative approach that smells more honest to me might be to reveal
 the fact that `catch#` is actually lazy in its argument, remove the `lazy`
 call from `catch`, and make `catchException` actually force its argument.
 I don't know if that would have any negative performance or other
 consequences.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13330#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler