#13194: Concurrent modifications of package.cache are not safe -------------------------------------+------------------------------------- Reporter: arybczak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by duncan): The `fnctl` semantics is problematic in general but not for our use case for ghc/ghc-pkg with the package.conf file. Making a general reusable API is nice, but not essential. The `flock` API is probably the one to go with, despite NFS issues. As for a suitable API, either internal or for more general consumption, the API presented by the filelock is a useful place to start (and it has good code we can borrow for the FFI bits). My first guess is that a reasonable route to try is to go with a `Handle` based API, like {{{ hLockFile :: Handle -> LockMode -> IO FileLock hTryLockFile :: Handle -> LockMode -> IO (Maybe FileLock) hUnlockFile :: Handle -> FileLock -> IO () withFileLock :: Handle -> LockMode -> (FileLock -> IO a) -> IO a }}} I'm not yet totally clear what lives in the `FileLock`. Is this for the sake of the Win32 API because it returns a lock handle? And perhaps `hUnlockFile` doesn't need the `Handle` too.
but that requires extracting file descriptor from Handle, which as far as I see is problematic.
It's actually totally possible. It simply fails for Handles that are not based on FDs, but that's ok. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13194#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler