[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