[GHC] #13296: stat() calls can block Haskell runtime

[GHC]

#13296: stat() calls can block Haskell runtime
-------------------------------------+-------------------------------------
        Reporter:  nh2               |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Runtime System    |              Version:  8.0.2
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Runtime           |  Unknown/Multiple
  performance bug                    |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by nh2):

 `slyfox` on IRC answers question (2):


 * slyfox: yeah, ghc's RTS does not limit amount of outstanding safe FFIs.
 example: http://dpaste.com/2YT058D
 * slyfox: `ghc --make a.hs -threaded -debug && time ./a +RTS -Ds` this
 runs in 6 seconds and nicely prints full list of blocked threads on FFI


 I've also put this into a gist and confirmed it on my GHC 8.0.2:
 https://gist.github.com/nh2/bcf583721213d34e9f464558a91a682e

 Further discussion:

 * rwbarton: stat() in a loop in C costs about 300ns per stat call here
 * nh2: much easier to program than building HTTP wrappers around all
 software, and basic * useful features
 * rwbarton: so 100ns for safe call overhead is kind of significant
 * nh2: slyfox: I guess asking for a better API is thinking ahead a bit too
 much when there * isn't even an async syscall interface for it in Linux
 yet
 * rwbarton: I think that is the API slyfox means
 * rwbarton: getFileStatus costs another 300 ns in userspace
 * rwbarton: so it would be about 100 ns more on top of 600 ns
 * nh2: rwbarton: that is a fair point, but it is hard to get completely
 right: on a local FS with a fast backend (e.g. ramdisk, SSD or FS metadata
 in the buffer cache), stat will be very fast, but if you are on a spinning
 disk on a part of FS metadata that's not currently cached, a NFS, or a
 network-mounted VM image (e.g. Amazon EBS and the various * equivalents),
 it'll be 1000x slower. And there's no way to tell on which you are

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13296#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler