[GHC] #13944: Introduce synchronized FFI
GHC
ghc-devs at haskell.org
Mon Jul 10 18:05:44 UTC 2017
#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
More information about the ghc-tickets
mailing list