#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 simonmar):
Ok, I'll add a cross-ref somewhere in the concurrency docs.
Replying to [comment:15 draconx]:
> > > 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
> > Are you claiming we have a problem with the overflow flag, or other
CPU
> > state?
>
> No, I didn't mean to suggest that there was any problem with the
handling of
> the integer overflow flag. I just wanted to draw a parallel to show
that the
> issues are the same; that floating point is not somehow special in this
regard.
>
> > I get the impression from your comments that you think GHC preempts
threads
> > at arbitrary points
>
> From the perspective of the application developer, this is exactly what
> happens, since it's essentially impossible to know in advance when
memory
> allocations will or will not occur. Furthermore, the wording in the
docs
> suggests that it's not even safe to rely on this. Statements such as
"threads
> are interleaved in a random fashion" and "GHC doesn't *currently*
attempt [to
> preempt tight loops]" (emphasis mine) suggest that threads might be
preempted
> for other reasons in the future.
That's not the point I was getting at. Your comments about saving
registers suggested to me that you were under the impression that GHC
could preempt a thread between two arbitrary instructions, when the
implementation doesn't do that, so I was trying to clarify. Yes this is
an implementation detail and irrelevant to the application programmer, but
that's beside the point.
> That's fine, but AFAIK there's no way for an application developer to
make the
> same guarantee that a safe point never occurs between an instruction
that sets
> the floating point overflow flag and one that tests it. Please correct
me if
> I'm wrong.
You're absolutely right - the application programmer has no way to write
code that interacts with the low-level details of the CPU such as the
floating point overflow flag (or the integer overflow flag, or the carry
flag etc.). This is regardless of safe points or threads, it's just not
something you can do.
Or perhaps I'm not understanding what you're getting at here. A concrete
example might help? Can you show me some code that you would expect to
work, but GHC doesn't implement correctly?
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4391#comment:16>
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
