search

haskell / hackage-security

Hackage security framework based on TUF (The Update Framework)
http://hackage.haskell.org/package/hackage-security
56 stars 47 forks source link

Use blocking file locking for cache lock #230

Closed bgamari closed 5 years ago

bgamari commented 5 years ago

Previously the cache lock operation (Hackage.Security.Client.Repository.Cache.lockCache) would try once to lock the cache directory and fail if the lock was already held. This leads to spurious failures in cabal-install due to its concurrent package fetching behavior.

In this case it's perfectly sensible to rather block.

bgamari commented 5 years ago

Note that this should work fine with cabal-install's concurrent fetching functionality. To see why consider downloadPackage:

downloadPackage rep@Repository{..} pkgId dest =                                              
     withMirror rep $                                                                         
          withIndex rep $ \IndexCallbacks{..} -> runVerify repLockCache $ do                     
             ...

The failing lock acquisition here was due to repLockCache. However, this lock is not held for the entire duration of the body enclosed by runVerify. Rather, it is only held when the finalizers of this block are run (e.g. when the downloaded file is copied into its final destination).

bgamari commented 5 years ago

Who is able to merge this?

hvr commented 5 years ago

I wonder whether the locking behaviour should rather be configurable; I can imagine situations in which I'd rather want cabal to give up after some amount of time than to block indefinitely on a stuck lock...