#15153: GHC uses O_NONBLOCK on regular files, which has no effect, and blocks the runtime -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Replying to [comment:3 simonmar]:
It's not usually a big problem except when the filesystem actually has significant latency, like with NFS or an arbitrary fuse filesystem.
I think I was worried about the overhead of using safe calls here, the
What about my example though? I'm just reading a 3GB file using `BS.readFile` and it blocks other threads for 30 seconds. (My file system doens't have unexpected latency in terms of access time, it's a normal spinning disk, and the problem is the time it takes to read the data. Though I find it reasonablye to argue that the ~8ms it may take to seek this disk is ''also'' a lot of wasted CPU time, that's not the key problem in my example.) problem is that if you have lots of threads all reading from Handles (e.g. sockets) then if those reads are safe calls we'll get a large number of real OS threads created. The concern about overhead makes sense to me, but I find it easy to argue that there's more overheard in having all other resources of a machine (CPU, network, other disks) idle while a single disk arm is moving. And the time for a `pthread_create` is rather small compared to a read of any physical storage device. Another argument is that if examples like the one I gave don't work, it is very hard to build reasonable heartbeating of long-running IO tasks in Haskell.
O_NONBLOCK doesn't do anything for local disk files, but it also doesn't do any harm
What I meant is that from a quick look at the code, it looked like if O_NONBLOCK isn't set, a `safe` call would be made instead. In the spirit of https://ghc.haskell.org/trac/ghc/ticket/13296#comment:3 and the followup comment, would it be a good default to have reads to be `safe`, and offer `unsafe` equivalents when you know that the read will be very fast? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15153#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler