GHC uses 300% CPU when calling into blocking C call

Hello,

I'm trying to write a program that modifies /etc/passwd safely, and so I wrote a function that looks like this:

lockPwd f = bracket main recover (\_ -> f)
  where
    mode = unionFileModes ownerReadMode ownerWriteMode
    main = do
      fd <- openFd "/etc/.pwd.lock" WriteOnly (Just mode) defaultFileFlags
      putStrLn "waiting to set lock"
      waitToSetLock fd (WriteLock, AbsoluteSeek, 0, 0)
      putStrLn "got lock"
      return fd
    recover = flip setLock (Unlock, AbsoluteSeek, 0, 0)

When I run it, my fans go wild, and CPU usage hits 300%.

/u/gelisam did some more in depth investigation here: https://www.reddit.com/r/haskell/comments/94wbfc/systemunixiowaittosetlock_call_results_in_300_cpu/e3p7sks/

Googling confirms that the parallel gc is using spin locks. So I think what is happening is that the waitToSetLock call makes the current thread unavailable for garbage collection (I don't know if that means the thread is "descheduled" as in the linked issue), which then causes the other threads to spin-lock while waiting for that thread at the next parallel GC. The problem still occurs with the latest release, GHC 8.4.3, and I could not find an existing issue describing the problem, so please file a ticket.

Maybe an argument could be made that this waitToSetLock call should be converted to be interruptible, but it also seems like I should be able to make my haskell program block patiently if I want it to.

Trac metadata

Trac field	Value
Version	8.4.3
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Runtime System
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture