[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:                    |
-------------------------------------+-------------------------------------

Comment (by bgamari):

 >I have did some benchmarks​ here, my conclusion is that under concurent
 disk I/O situations, safe FFI can cause a slow down up to 50%.

 I can't reproduce this result. I've checked out your benchmark and see the
 following,

 == unsafe ==
 {{{
 [1250 ben at ben-laptop diskIO(master)] $ time bin/unsafe-ffi 10m

 real    0m0.657s
 user    0m0.000s
 sys     0m1.035s
 [1251 ben at ben-laptop diskIO(master)] $ time bin/unsafe-ffi 10m

 real    0m1.766s
 user    0m0.000s
 sys     0m1.912s
 [1251 ben at ben-laptop diskIO(master)] $ time bin/unsafe-ffi 10m

 real    0m1.460s
 user    0m0.008s
 sys     0m1.570s
 }}}

 == safe ==
 {{{
 [1252 ben at ben-laptop diskIO(master)] $ time bin/safe-ffi 10m

 real    0m0.867s
 user    0m0.000s
 sys     0m0.966s
 [1252 ben at ben-laptop diskIO(master)] $ time bin/safe-ffi 10m
 ^[[A

 real    0m0.473s
 user    0m0.001s
 sys     0m0.636s
 [1252 ben at ben-laptop diskIO(master)] $ time bin/safe-ffi 10m

 real    0m0.794s
 user    0m0.009s
 sys     0m0.864s
 }}}

 If anything, it seems that `safe` FFI is dramatically **faster** than
 `unsafe`. Admittedly this is rather surprising, but I wouldn't expect a
 factor of two slower for this particular test. In the `safe` case `perf`
 confirmed that less than 3% of runtime was spent in `suspendThread` and
 `resumeThread` combined.

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