#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: | -------------------------------------+------------------------------------- Description changed by winter: @@ -20,0 +20,4 @@ + 4. When the FFI finish, if we're GC ing, put current capaity into sleep(if + we can find a way to let it join parallel GC that would be better). + Otherwise it continue to work. + @@ -23,1 +27,2 @@ - anyway. + anyway, we can combine this with the new `-qn` RTS parameter: as long as + there're more than `n` threads can join GC, we do GC. New description: During hacking on ghc I/O libraries, i find an [https://github.com/winterland1989/stdio/tree/master/bench/diskIO interesting situation], to summarize: There're some FFI calls that vary a lot in time duration, this makes unsafe FFI bad because it make GC hard to synchronize all capacities. OTOH safe FFI 's overhead is too large to justify its usage. After some thought i think we should introduce a new FFI type, let call it `synchronized` for now, it should: 1. Have the same requirement as safe FFI of what kind of argument we can pass, e.g. pinned ByteArray, pass by value primitive type, etc. 2. It works like unsafe FFI call by directly jump to c code using current capacity's stack. 3. It should mark current capacity GC ready, and doesn't participate next GC. 4. When the FFI finish, if we're GC ing, put current capaity into sleep(if we can find a way to let it join parallel GC that would be better). Otherwise it continue to work. The point is that if a FFI call doesn't need GC guarantee, then it shouldn't stop GC running. The next GC will not be running with all threads, but that's not too terrible since it doesn't scale too much anyway, we can combine this with the new `-qn` RTS parameter: as long as there're more than `n` threads can join GC, we do GC. -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13944#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler