[GHC] #13944: Introduce synchronized FFI

[GHC]

#13944: Introduce synchronized FFI
-------------------------------------+-------------------------------------
        Reporter:  winter            |                Owner:  (none)
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:  8.4.1
       Component:  Compiler          |              Version:  8.0.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Description changed by winter:

@@ -8,1 +8,1 @@
- After some though i think we should Introduce a new FFI type, let call it
+ After some thought i think we should introduce a new FFI type, let call it

New description:

 During hacking on ghc I/O libraries, i find an
 [https://github.com/winterland1989/stdio/tree/master/bench/diskIO
 interesting situation], to summarize: There're some FFI calls that vary a
 lot in time duration, this makes unsafe FFI bad because it make GC hard to
 synchronize all capacities. OTOH safe FFI 's overhead is too large to
 justify its usage.

 After some thought i think we should introduce a new FFI type, let call it
 `synchronized` for now, it should:

 1. Have the same requirement as safe FFI of what kind of argument we can
 pass, e.g. pinned ByteArray, pass by value primitive type, etc.

 2. It works like unsafe FFI call by directly jump to c code using current
 capacity's stack.

 3. It should mark current capacity GC ready, and doesn't participate next
 GC.

 The point is that if a FFI call doesn't need GC guarantee, then it
 shouldn't stop GC running. The next GC will not be running with all
 threads, but that's not too terrible since it doesn't scale too much
 anyway.

--

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