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

GHC ghc-devs at haskell.org
Fri Feb 24 23:29:39 UTC 2017


#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 rwbarton):

 Replying to [comment:5 dfeuer]:
 > 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.

 Agreed, though we might also document what could happen if the argument
 actually is bottom (namely `catch#` will not catch the exception).

 > 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.

 Interesting idea. It would mean an extra `seq` in the original program,
 but I think GHC would normally be able to eliminate the `seq` easily.

 If this works it might lead to a simpler design; but not urgent.

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


More information about the ghc-tickets mailing list