2015-05-18 18:16:49 +00:00
|
|
|
{- Posix lock files, using lock pools.
|
|
|
|
-
|
|
|
|
- Copyright 2015 Joey Hess <id@joeyh.name>
|
|
|
|
-
|
|
|
|
- License: BSD-2-clause
|
|
|
|
-}
|
|
|
|
|
|
|
|
module Utility.LockPool.Posix (
|
2015-10-08 18:27:37 +00:00
|
|
|
P.LockFile,
|
2015-05-18 18:16:49 +00:00
|
|
|
LockHandle,
|
|
|
|
lockShared,
|
|
|
|
lockExclusive,
|
2015-10-08 17:40:23 +00:00
|
|
|
tryLockShared,
|
2015-05-18 18:16:49 +00:00
|
|
|
tryLockExclusive,
|
|
|
|
checkLocked,
|
|
|
|
getLockStatus,
|
2015-05-20 03:35:24 +00:00
|
|
|
LockStatus(..),
|
2015-05-18 18:16:49 +00:00
|
|
|
dropLock,
|
|
|
|
checkSaneLock,
|
|
|
|
) where
|
|
|
|
|
|
|
|
import qualified Utility.LockFile.Posix as F
|
2015-11-12 19:38:02 +00:00
|
|
|
import Utility.LockFile.LockStatus
|
2015-05-18 18:16:49 +00:00
|
|
|
import qualified Utility.LockPool.STM as P
|
2015-05-18 20:23:07 +00:00
|
|
|
import Utility.LockPool.STM (LockFile, LockMode(..))
|
2015-05-18 18:16:49 +00:00
|
|
|
import Utility.LockPool.LockHandle
|
|
|
|
|
|
|
|
import System.IO
|
|
|
|
import System.Posix
|
|
|
|
import Data.Maybe
|
|
|
|
import Control.Applicative
|
|
|
|
import Prelude
|
|
|
|
|
|
|
|
-- Takes a shared lock, blocking until the lock is available.
|
|
|
|
lockShared :: Maybe FileMode -> LockFile -> IO LockHandle
|
Fix shared lock file FD leak.
This fixes behavior in this situation:
l1 <- lockShared Nothing "lck"
l2 <- lockShared Nothing "lck"
dropLock l1
dropLock l2
Before, the lock was dropped upon the second dropLock call, but the fd
remained open, and would never be closed while the program was running.
Fixed by a rather round-about method, but it should work well enough.
It would have been simpler to open open the shared lock once, and not open
it again in the second call to lockShared. But, that's difficult to do
atomically.
This also affects Windows and PID locks, not just posix locks.
In the case of pid locks, multiple calls to waitLock within the same
process are allowed because the side lock is locked using a posix lock,
and so multiple exclusive locks can be taken in the same process. So,
this change fixes a similar problem with pid locks.
l1 <- waitLock (Seconds 1) "lck"
l2 <- waitLock (Seconds 1) "lck"
dropLock l1
dropLock l2
Here the l2 side lock fd remained open but not locked,
although the pid lock file was removed. After this change, the second
dropLock will close both fds to the side lock, and delete the pidlock.
2016-03-01 19:31:39 +00:00
|
|
|
lockShared mode file = makeLockHandle P.lockPool file
|
|
|
|
(\p f -> P.waitTakeLock p f LockShared)
|
|
|
|
(\f -> mk <$> F.lockShared mode f)
|
2015-05-18 18:16:49 +00:00
|
|
|
|
2015-10-08 17:40:23 +00:00
|
|
|
-- Takes an exclusive lock, blocking until the lock is available.
|
2015-05-18 18:16:49 +00:00
|
|
|
lockExclusive :: Maybe FileMode -> LockFile -> IO LockHandle
|
Fix shared lock file FD leak.
This fixes behavior in this situation:
l1 <- lockShared Nothing "lck"
l2 <- lockShared Nothing "lck"
dropLock l1
dropLock l2
Before, the lock was dropped upon the second dropLock call, but the fd
remained open, and would never be closed while the program was running.
Fixed by a rather round-about method, but it should work well enough.
It would have been simpler to open open the shared lock once, and not open
it again in the second call to lockShared. But, that's difficult to do
atomically.
This also affects Windows and PID locks, not just posix locks.
In the case of pid locks, multiple calls to waitLock within the same
process are allowed because the side lock is locked using a posix lock,
and so multiple exclusive locks can be taken in the same process. So,
this change fixes a similar problem with pid locks.
l1 <- waitLock (Seconds 1) "lck"
l2 <- waitLock (Seconds 1) "lck"
dropLock l1
dropLock l2
Here the l2 side lock fd remained open but not locked,
although the pid lock file was removed. After this change, the second
dropLock will close both fds to the side lock, and delete the pidlock.
2016-03-01 19:31:39 +00:00
|
|
|
lockExclusive mode file = makeLockHandle P.lockPool file
|
|
|
|
(\p f -> P.waitTakeLock p f LockExclusive)
|
|
|
|
(\f -> mk <$> F.lockExclusive mode f)
|
2015-05-18 18:16:49 +00:00
|
|
|
|
2015-10-08 17:40:23 +00:00
|
|
|
-- Tries to take a shared lock, but does not block.
|
|
|
|
tryLockShared :: Maybe FileMode -> LockFile -> IO (Maybe LockHandle)
|
Fix shared lock file FD leak.
This fixes behavior in this situation:
l1 <- lockShared Nothing "lck"
l2 <- lockShared Nothing "lck"
dropLock l1
dropLock l2
Before, the lock was dropped upon the second dropLock call, but the fd
remained open, and would never be closed while the program was running.
Fixed by a rather round-about method, but it should work well enough.
It would have been simpler to open open the shared lock once, and not open
it again in the second call to lockShared. But, that's difficult to do
atomically.
This also affects Windows and PID locks, not just posix locks.
In the case of pid locks, multiple calls to waitLock within the same
process are allowed because the side lock is locked using a posix lock,
and so multiple exclusive locks can be taken in the same process. So,
this change fixes a similar problem with pid locks.
l1 <- waitLock (Seconds 1) "lck"
l2 <- waitLock (Seconds 1) "lck"
dropLock l1
dropLock l2
Here the l2 side lock fd remained open but not locked,
although the pid lock file was removed. After this change, the second
dropLock will close both fds to the side lock, and delete the pidlock.
2016-03-01 19:31:39 +00:00
|
|
|
tryLockShared mode file = tryMakeLockHandle P.lockPool file
|
|
|
|
(\p f -> P.tryTakeLock p f LockShared)
|
|
|
|
(\f -> fmap mk <$> F.tryLockShared mode f)
|
2015-10-08 17:40:23 +00:00
|
|
|
|
|
|
|
-- Tries to take an exclusive lock, but does not block.
|
2015-05-18 18:16:49 +00:00
|
|
|
tryLockExclusive :: Maybe FileMode -> LockFile -> IO (Maybe LockHandle)
|
Fix shared lock file FD leak.
This fixes behavior in this situation:
l1 <- lockShared Nothing "lck"
l2 <- lockShared Nothing "lck"
dropLock l1
dropLock l2
Before, the lock was dropped upon the second dropLock call, but the fd
remained open, and would never be closed while the program was running.
Fixed by a rather round-about method, but it should work well enough.
It would have been simpler to open open the shared lock once, and not open
it again in the second call to lockShared. But, that's difficult to do
atomically.
This also affects Windows and PID locks, not just posix locks.
In the case of pid locks, multiple calls to waitLock within the same
process are allowed because the side lock is locked using a posix lock,
and so multiple exclusive locks can be taken in the same process. So,
this change fixes a similar problem with pid locks.
l1 <- waitLock (Seconds 1) "lck"
l2 <- waitLock (Seconds 1) "lck"
dropLock l1
dropLock l2
Here the l2 side lock fd remained open but not locked,
although the pid lock file was removed. After this change, the second
dropLock will close both fds to the side lock, and delete the pidlock.
2016-03-01 19:31:39 +00:00
|
|
|
tryLockExclusive mode file = tryMakeLockHandle P.lockPool file
|
|
|
|
(\p f -> P.tryTakeLock p f LockExclusive)
|
|
|
|
(\f -> fmap mk <$> F.tryLockExclusive mode f)
|
2015-05-18 18:16:49 +00:00
|
|
|
|
|
|
|
-- Returns Nothing when the file doesn't exist, for cases where
|
|
|
|
-- that is different from it not being locked.
|
|
|
|
checkLocked :: LockFile -> IO (Maybe Bool)
|
2015-05-20 03:35:24 +00:00
|
|
|
checkLocked file = P.getLockStatus P.lockPool file
|
|
|
|
(pure (Just True))
|
2015-05-18 18:16:49 +00:00
|
|
|
(F.checkLocked file)
|
|
|
|
|
2015-05-20 03:35:24 +00:00
|
|
|
getLockStatus :: LockFile -> IO LockStatus
|
|
|
|
getLockStatus file = P.getLockStatus P.lockPool file
|
|
|
|
(StatusLockedBy <$> getProcessID)
|
2015-05-18 18:16:49 +00:00
|
|
|
(F.getLockStatus file)
|
|
|
|
|
2015-11-12 20:28:11 +00:00
|
|
|
mk :: F.LockHandle -> FileLockOps
|
|
|
|
mk h = FileLockOps
|
|
|
|
{ fDropLock = F.dropLock h
|
|
|
|
, fCheckSaneLock = \f -> F.checkSaneLock f h
|
|
|
|
}
|