[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 winter):

 > Alright, I think I see what you want. So you are targetting applications
 where you have a potentially-blocking foreign call and therefore can't use
 `unsafe` calls but want to avoid the cost associated with suspending a
 Haskell thread.

 Exactly! For example current I/O manager first perform an unsafe read and
 check if result is eAgain, but for regular file it will never return
 eAgain, which turn this unsafe read into a blocking read. If unfortunately
 OS didn't manage page cache for us, we end up with a long capacity
 blocking read.

 > The problem is that, other than perhaps the stack walk, I don't think
 any of these costs can be avoided. Afterall, we need to save the thread
 state to the TSO in order to safely GC (since TSOs are GC roots). I
 suspect it would also be necessary to lock the capability.

 Is there a way to do it lazily? By say lazily i meaning, can we just
 perform the FFI call and mark the capacity with some kind of `SYNC` flag.
 If a GC thread is asking for sync during FFI, then let it perform these
 stack saving for us. Otherwise we just happily continue, and saving all
 the overheads.

 I think this might work since once we enter a FFI call, the haskell
 thread's stack are not touch anymore, and the whole capacity is freezed.

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