#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