[GHC] #4391: forkIO threads do not properly save/restore the floating point environment

GHC cvs-ghc at haskell.org
Mon Nov 29 14:26:17 CET 2010


#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


More information about the Glasgow-haskell-bugs mailing list