[GHC] #8281: The impossible happened: primRepToFFIType

[GHC]

#8281: The impossible happened: primRepToFFIType
-------------------------------------+-------------------------------------
        Reporter:  tibbe             |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  high              |            Milestone:  8.4.1
       Component:  Compiler          |              Version:  7.6.2
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Compile-time      |  Unknown/Multiple
  crash                              |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by simonmar):

 @bgamari I understand the concerns and I agree.

 To answer your question about the rationale, the idea is that "safe" is
 the default and "unsafe" relaxes the compiler's obligations only.  It
 doesn't add new obligations (such as the requirement not to interrupt the
 call with a GC).  Implementing that obligation in GHCi might be possible,
 but we haven't done it.

 One way around this would be to add a new annotation to foreign calls that
 requires the call not to be interrupted by GC, e.g. `foreign import
 unsafenogc ...` or something.  This would not be implemented by GHCi
 (yet?) so compilation would fail if you tried to load text into GHCi.

 Incidentally it's a bad idea to make one of these calls that might run for
 an arbitrarily long time, because if a GC strikes everything is blocked
 until the call returns.  This has been a rich source of performance bugs
 in our system at Facebook.  I don't think we've encountered problems with
 text, but we've had to fix other libraries (e.g. regex-pcre) to turn
 unsafe calls into safe calls. It's possible that the unsafe calls in Text
 would cause problems when working with very long strings.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8281#comment:20>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler