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,239
    • Issues 5,239
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 566
    • Merge requests 566
  • 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
  • Issues
  • #13296
Closed
Open
Issue created Feb 18, 2017 by Niklas Hambüchen@nh2Reporter

stat() calls can block Haskell runtime

getFileStatus (stat() syscall) is marked as unsafe, which means that if I have e.g. +RTS -N4, I can't stat more than 4 files at the same time without completely stopping the Haskell world.

This is an issue on network file systems, where a single stat() can easily take 2 milliseconds, so you typically want to do them in parallel (but due to the above you can't).

The underlying problem is that there are some Linux syscalls you typically need on networked file systems that have no asynchronous equivalent; according to http://blog.libtorrent.org/2012/10/asynchronous-disk-io/ these are at least:

  • stat()
  • open()
  • fallocate()
  • rename()

A quick skim through libraries/base/System/Posix/Internals.hs reveals the situation:

  • stat() only exists as unsafe
  • open() has both safe and unsafe variants (I haven't checked which one is used in practice)

The remaining ones are in the unix package

  • fallocate() is safe
  • rename() is unsafe

It seems to me that there are two issues here:

  1. None of these calls should be unsafe because they may block for a very long time (e.g. > 0.5 ms even on the fastest LANs).

  2. We need to answer the question: If we marked them as safe, how many of them would the RTS execute in parallel? To my current knowledge (thanks rwbarton and slyfox on #ghc), there's a pool of Haskell executing threads (the usual -RTS -N), and a pool of FFI threads. Are there any restrictions on the size of that latter pool? The docs https://downloads.haskell.org/\~ghc/latest/docs/html/users_guide/ffi-chap.html\#foreign-imports-and-multi-threading are not specific on that topic, simply mentioning "but there may be an arbitrary number of foreign calls in progress at any one time, regardless of the +RTS -N value". Does that mean the amount of FFI threads is truly unbounded?

Trac metadata
Trac field Value
Version 8.0.2
Type Bug
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component Runtime System
Test case
Differential revisions
BlockedBy
Related
Blocking
CC rwbarton, simonmar, slyfox
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