Skip to content
GitLab
Projects Groups Snippets
  • /
  • 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 5,244
    • Issues 5,244
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 571
    • Merge requests 571
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell CompilerGlasgow Haskell Compiler
  • GHCGHC
  • Merge requests
  • !4942

uninterruptible closeFdWith

  • Review changes

  • Download
  • Email patches
  • Plain diff
Closed Marcin Szamotulski requested to merge coot/ghc:coot/uninterruptible-closeFdWith into master Feb 04, 2021
  • Overview 5
  • Commits 2
  • Pipelines 1
  • Changes 2

closeFdWith ought to be uninterruptible, since functions like hClose or Network.Socket.close are commonly used by bracket which only masks exceptions.

I explained here why closeFdWith can block (and thus interrupted by async exceptions), but I'll repeat the argument here for convenience.

closeFdWith is using takeMVar on two levels: it needs to access each EventManager, and for each of them it needs to get appropriate entry in the Array Int (MVar (IntTable [FdData])). A file descriptor is hashed and that hash is the entry in the array. The array has 32 entries, so hash collisions are expected.

Since this callback table might contain information about different file descriptors, it might be accessed concurrently by different threads, thus the inner takeMVar might block, although for a very short time as all the operations are using epoll (or a platform specific equivalent).

Since accessing the inner MVar (through callbackTableVar) might block, also accessing the MVar which holds EventManager can also block, but the only reason I can see why it would block is the one I gave above.

By making closeFdWith uninterruptible, we will guarantee that using hClose and Network.Socket.close is safe when used with bracket (interruptible close handler used in a bracket can leak a resource).

Assignee
Assign to
Reviewers
Request review from
Time tracking
Source branch: coot/uninterruptible-closeFdWith