Skip to content

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
    • Help
    • Support
    • Submit feedback
  • Sign in / Register
GHC
GHC
  • Project
    • Project
    • Details
    • Activity
    • Releases
    • Cycle Analytics
    • Insights
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Charts
    • Locked Files
  • Issues 3,626
    • Issues 3,626
    • List
    • Boards
    • Labels
    • Milestones
  • Merge Requests 201
    • Merge Requests 201
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Charts
  • Security & Compliance
    • Security & Compliance
    • Dependency List
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Charts
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • Glasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #5897

Closed
Open
Opened Feb 26, 2012 by sanketr@trac-sanketr
  • Report abuse
  • New issue
Report abuse New issue

GHC runtime task workers are not released with C FFI

I have a test code which calls C FFI to collect data every n microseconds. The timer event in Haskell code spawns one thread for each C FFI thread. Those C FFI threads call back, and coordinates with calling GHC thread through mvar. What I am consistently seeing is the increase in number of runtime task workers with each iteration of timer event. The attached test code reproduces the issue (please see attached README on how to run it).

I tested these on both Mac and Redhat Linux x86_64 with GHC 7.4.1, and was able to reliably reproduce the issue.

The end result is that if number of C FFI threads is beyond a certain threshold (6 on my quad-core iMac), the number of runtime tasks seem to increase without bounds. For example, here is a sample RTS output from attached test code, with 7 C FFI threads, and 2 GHC threads, after two iterations of the call to C FFI - instead of 4 task workers, there are 10 - tested with "-N3 +RTS -s" on GHC 7.4.1 and Mac 10.7.2 (quad-core iMac):

Parallel GC work balance: nan (0 / 0, ideal 1)

                        MUT time (elapsed)       GC time  (elapsed)
  Task  0 (worker) :    0.00s    (  0.42s)       0.00s    (  0.00s)
  Task  1 (worker) :    0.00s    (  0.00s)       0.00s    (  0.00s)
  Task  2 (worker) :    0.00s    (  0.93s)       0.00s    (  0.00s)
  Task  3 (worker) :    0.00s    (  0.93s)       0.00s    (  0.00s)
  Task  4 (worker) :    0.00s    (  0.93s)       0.00s    (  0.00s)
  Task  5 (worker) :    0.00s    (  0.93s)       0.00s    (  0.00s)
  Task  6 (worker) :    0.00s    (  0.93s)       0.00s    (  0.00s)
  Task  7 (worker) :    0.06s    (  1.00s)       0.00s    (  0.00s)
  Task  8 (worker) :    0.00s    (  0.00s)       0.00s    (  0.00s)
  Task  9 (worker) :    0.06s    (  1.43s)       0.00s    (  0.00s)
  Task 10 (bound)  :    0.00s    (  0.00s)       0.00s    (  0.00s)

The culprit seems to be mvar callback by C FFI. If I remove mvar callback, the number of task workers stay constant at 4.

If this is a bug in GHC runtime and not my code, it seems to be a big bug because mvar callback is important for coordination with C FFI threads. This bug might have been in previous versions of GHC as well, but probably not discovered because it seems to require a certain C FFI thread count threshold to kick in.

Trac metadata
Trac field Value
Version 7.4.1
Type Bug
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component Runtime System
Test case
Differential revisions
BlockedBy
Related #4262 (closed)
Blocking
CC sanket.agrawal@gmail.com
Operating system
Architecture

Related issues

  • Discussion
  • Designs
Assignee
Assign to
7.4.3
Milestone
7.4.3
Assign milestone
Time tracking
None
Due date
None
5
Labels
bug FFI P::highest RTS Trac import
Assign labels
  • View project labels
Reference: ghc/ghc#5897