#8591: Concurrent executions of ghc-pkg can cause inconstant package.cache files -------------------------------------+------------------------------------- Reporter: janm | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package | Version: 7.6.3 system | Keywords: ghc-pkg race Resolution: | Architecture: Unknown/Multiple Operating System: FreeBSD | Difficulty: Unknown Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by janm): Replying to [comment:1 thomie]:
The comment [https://github.com/ghc/ghc/blob/74a6a8a979837d1344fc3236ad6fc4ca76ea49a7/uti... /ghc-pkg/Main.hs#L1984 "Big fat hairy race condition"] might have something to do with this.
That comment is in the MINGW32 host or target branch of the #if, dealing with the case where renameFile can't rename over an existing file on the Win32 platform. The real race is depending on renameFile at all, as in the #else case of of that #if, as is the case on the platform I'm using, FreeBSD. The "atomic property" referred to in the comment here is for single- process execution, the race I'm talking about is the race between two processes to call renameFile. A better approach would be for the process to open the targetFile with O_EXCL (and create it with O_CREAT if it doesn't exist), and hold it open while doing the atomic rename on top of the target. That way the targetFile is used a lock to synchronise updates between concurrent processes. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8591#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler