forkIO threads do not properly save/restore the floating point environment

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

Trac metadata

Trac field	Value
Version	6.12.3
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture