#4391: forkIO threads do not properly save/restore the floating point
environment
---------------------------------+------------------------------------------
Reporter: draconx | Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 6.12.3 | Keywords:
Testcase: | Blockedby:
Os: Unknown/Multiple | Blocking:
Architecture: x86_64 (amd64) | Failure: None/Unknown
---------------------------------+------------------------------------------
When using forkIO threads, the floating point environment is not correctly
saved and/or restored on context switches. This causes floating point
state
to leak between the threads.
For example, if two threads (call them A and B) are created, and thread A
changes the rounding direction, computations in thread B will be carried
out
under the rounding direction set by A, and vice versa. Likewise, any
exceptions raised by computations in thread A are visible in thread B.
If forkIO threads are not intended to be used with floating point, this
should
be spelled out explicitly in the documentation rather than some vague
notion of
avoiding "thread local state".
I've attached a short test program which demonstrates this issue. For
portability, it uses standard C library functions to manipulate the
floating
point environment. It prints the following when compiled with GHC
(parenthetical statements added):
{{{
A: ToNearest (default rounding mode)
A: True
B: ToNearest
B: TowardZero
B: Infinity (result of division by 0)
A: [DivByZero] (A sees B's exception)
A: TowardZero (A sees B's rounding direction)
A: False
}}}
If we use OS threads (which properly save/restore the floating point
environment):
{{{
A: ToNearest
A: True
B: ToNearest
B: TowardZero
B: Infinity (result of division by zero)
A: [] (no new exceptions are visible)
A: ToNearest (rounding direction is unchanged)
A: True
}}}
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4391>
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
