#4391: forkIO threads do not properly save/restore the floating point
environment
---------------------------------+------------------------------------------
Reporter: draconx | Owner:
Type: bug | Status: merge
Priority: normal | Milestone: 7.2.1
Component: Runtime System | Version: 6.12.3
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: x86_64 (amd64) | Failure: None/Unknown
---------------------------------+------------------------------------------
Comment(by draconx):
The fenv.h functions are standard C, not limited to POSIX systems. Also,
this
IMO needs to be in the Control.Concurrent manual, because this has
everything
to do with threads and nothing to do with the FFI.
About purity: the thing is, even if we had the perfect pure API for
floating
point, you'd _still_ be bitten by this issue! That's because the issue is
not
about purity at all: it's about the runtime clobbering CPU registers on
context
switches. Note that integer operations on a certain popular CPU
architecture
are just as "impure" as floating point: there is a register which stores
flags
such as overflow state that is modified by operations (this register
performs
essentially identical function to the floating point control word on that
same popular architecture). But nobody would posit that "all bets are
off"
because a program uses conditional branches! No amount of purity will
save
you from silent data corruption.
Nevertheless, I overestimated the damage: using bound threads appears to
be a
suitable workaround. I was under the impression that a bound thread could
be
pre-empted by an unbound thread, but some testing reveals this to not be
the
case.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4391#comment:13>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
