fix liveupdate locking
This fixes the build on windows. Changed it to use lock pools, which will behave better if two threads call getLiveRepoSizes at the same time. Also this should make it work when annex.pidlock is set. In that case, once the current process locks this file, or anything, any other process will have to wait on the pid lock. So checkStaleSizeChanges will correctly identify any other live changes in the database as stale, since there can only be one git-annex process running.
This commit is contained in:
parent
c10d11959a
commit
3b74386ed4
2 changed files with 16 additions and 2 deletions
|
@ -1,6 +1,6 @@
|
|||
{- git-annex lock files.
|
||||
-
|
||||
- Copyright 2012-2020 Joey Hess <id@joeyh.name>
|
||||
- Copyright 2012-2024 Joey Hess <id@joeyh.name>
|
||||
-
|
||||
- Licensed under the GNU AGPL version 3 or higher.
|
||||
-}
|
||||
|
@ -16,6 +16,7 @@ module Annex.LockFile (
|
|||
withExclusiveLock,
|
||||
takeExclusiveLock,
|
||||
tryExclusiveLock,
|
||||
trySharedLock,
|
||||
) where
|
||||
|
||||
import Annex.Common
|
||||
|
@ -111,3 +112,16 @@ tryExclusiveLock lockfile a = debugLocks $ do
|
|||
unlock = maybe noop dropLock
|
||||
go Nothing = return Nothing
|
||||
go (Just _) = Just <$> a
|
||||
|
||||
{- Tries to take a shared lock, without blocking.
|
||||
-
|
||||
- Does not create the lock directory or lock file if it does not exist,
|
||||
- taking an exclusive lock will create them.
|
||||
-}
|
||||
trySharedLock :: RawFilePath -> Annex (Maybe LockHandle)
|
||||
trySharedLock lockfile = debugLocks $
|
||||
#ifndef mingw32_HOST_OS
|
||||
tryLockShared Nothing lockfile
|
||||
#else
|
||||
liftIO $ lockShared lockfile
|
||||
#endif
|
||||
|
|
|
@ -177,7 +177,7 @@ checkStaleSizeChanges h@(RepoSizeHandle (Just _) livev) = do
|
|||
|
||||
checkstale livedir lockfile pid =
|
||||
let f = livedir P.</> toRawFilePath lockfile
|
||||
in tryLockShared Nothing f >>= \case
|
||||
in trySharedLock f >>= \case
|
||||
Nothing -> return Nothing
|
||||
Just lck -> do
|
||||
return $ Just
|
||||
|
|
Loading…
Reference in a new issue