Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • GHC GHC
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 4,836
    • Issues 4,836
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 459
    • Merge requests 459
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
    • Value stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #5897

Closed
Open
Created Feb 26, 2012 by sanketr@trac-sanketr

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
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking