#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): 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. This cost comes in a variety of forms, 1. a stack walk, due to the duplicate computation check in `suspendThread` 2. a few lock operations to safely modify the capability 3. the cost of saving and restoring the thread state to the TSO Judging from this I'd guess this will cost anywhere from hundreds to thousands of cycles (largely depending upon stack depth, I suspect), and consequently it seems plausible that we'd want a way to avoid this. Have you done any characterisation of this? 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. Consequently, it's really not clear to me that this new call type would pull its weight. It would be helpful if we had actual measurements of how much the various contributions above cost. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13944#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler