2015-05-18 18:16:49 +00:00
|
|
|
{- STM implementation of lock pools.
|
|
|
|
-
|
|
|
|
- Copyright 2015 Joey Hess <id@joeyh.name>
|
|
|
|
-
|
|
|
|
- License: BSD-2-clause
|
|
|
|
-}
|
|
|
|
|
|
|
|
module Utility.LockPool.STM (
|
|
|
|
LockPool,
|
|
|
|
lockPool,
|
|
|
|
LockFile,
|
|
|
|
LockMode(..),
|
|
|
|
LockHandle,
|
|
|
|
waitTakeLock,
|
|
|
|
tryTakeLock,
|
|
|
|
getLockStatus,
|
|
|
|
releaseLock,
|
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
|
|
|
CloseLockFile,
|
|
|
|
registerCloseLockFile,
|
2015-05-18 18:16:49 +00:00
|
|
|
) where
|
|
|
|
|
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
|
|
|
import Utility.Monad
|
|
|
|
|
2015-05-18 18:16:49 +00:00
|
|
|
import System.IO.Unsafe (unsafePerformIO)
|
|
|
|
import qualified Data.Map.Strict as M
|
|
|
|
import Control.Concurrent.STM
|
|
|
|
import Control.Exception
|
|
|
|
import Control.Monad
|
2015-05-31 20:54:07 +00:00
|
|
|
import Control.Applicative
|
|
|
|
import Prelude
|
2015-05-18 18:16:49 +00:00
|
|
|
|
|
|
|
type LockFile = FilePath
|
|
|
|
|
|
|
|
data LockMode = LockExclusive | LockShared
|
|
|
|
deriving (Eq)
|
|
|
|
|
|
|
|
-- This TMVar is full when the handle is open, and is emptied when it's
|
|
|
|
-- closed.
|
|
|
|
type LockHandle = TMVar (LockPool, LockFile)
|
|
|
|
|
|
|
|
type LockCount = Integer
|
|
|
|
|
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
|
|
|
data LockStatus = LockStatus LockMode LockCount CloseLockFile
|
|
|
|
|
|
|
|
type CloseLockFile = IO ()
|
2015-05-18 18:16:49 +00:00
|
|
|
|
|
|
|
-- This TMVar is normally kept full.
|
|
|
|
type LockPool = TMVar (M.Map LockFile LockStatus)
|
|
|
|
|
|
|
|
-- A shared global variable for the lockPool. Avoids callers needing to
|
|
|
|
-- maintain state for this implementation detail.
|
2017-05-25 20:02:17 +00:00
|
|
|
{-# NOINLINE lockPool #-}
|
2015-05-18 18:16:49 +00:00
|
|
|
lockPool :: LockPool
|
|
|
|
lockPool = unsafePerformIO (newTMVarIO M.empty)
|
|
|
|
|
|
|
|
-- Updates the LockPool, blocking as necessary if another thread is holding
|
|
|
|
-- a conflicting lock.
|
|
|
|
--
|
|
|
|
-- Note that when a shared lock is held, an exclusive lock will block.
|
|
|
|
-- While that blocking is happening, another call to this function to take
|
|
|
|
-- the same shared lock should not be blocked on the exclusive lock.
|
|
|
|
-- Keeping the whole Map in a TMVar accomplishes this, at the expense of
|
|
|
|
-- sometimes retrying after unrelated changes in the map.
|
|
|
|
waitTakeLock :: LockPool -> LockFile -> LockMode -> STM LockHandle
|
2017-05-25 20:02:17 +00:00
|
|
|
waitTakeLock pool file mode = maybe retry return =<< tryTakeLock pool file mode
|
2015-05-18 18:16:49 +00:00
|
|
|
|
|
|
|
-- Avoids blocking if another thread is holding a conflicting lock.
|
|
|
|
tryTakeLock :: LockPool -> LockFile -> LockMode -> STM (Maybe LockHandle)
|
2017-05-25 20:02:17 +00:00
|
|
|
tryTakeLock pool file mode = do
|
|
|
|
m <- takeTMVar pool
|
|
|
|
let success v = do
|
|
|
|
putTMVar pool (M.insert file v m)
|
|
|
|
Just <$> newTMVar (pool, file)
|
|
|
|
case M.lookup file m of
|
|
|
|
Just (LockStatus mode' n closelockfile)
|
|
|
|
| mode == LockShared && mode' == LockShared ->
|
|
|
|
success $ LockStatus mode (succ n) closelockfile
|
|
|
|
| n > 0 -> do
|
|
|
|
putTMVar pool m
|
|
|
|
return Nothing
|
|
|
|
_ -> success $ LockStatus mode 1 noop
|
2015-05-18 18:16:49 +00:00
|
|
|
|
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
|
|
|
-- Call after waitTakeLock or tryTakeLock, to register a CloseLockFile
|
|
|
|
-- action to run when releasing the lock.
|
|
|
|
registerCloseLockFile :: LockPool -> LockFile -> CloseLockFile -> STM ()
|
|
|
|
registerCloseLockFile pool file closelockfile = do
|
|
|
|
m <- takeTMVar pool
|
|
|
|
putTMVar pool (M.update go file m)
|
|
|
|
where
|
|
|
|
go (LockStatus mode n closelockfile') = Just $
|
|
|
|
LockStatus mode n (closelockfile' >> closelockfile)
|
|
|
|
|
2015-05-18 18:16:49 +00:00
|
|
|
-- Checks if a lock is being held. If it's held by the current process,
|
|
|
|
-- runs the getdefault action; otherwise runs the checker action.
|
|
|
|
--
|
|
|
|
-- Note that the lock pool is left empty while the checker action is run.
|
|
|
|
-- This allows checker actions that open/close files, and so would be in
|
2015-05-18 20:23:07 +00:00
|
|
|
-- danger of conflicting with locks created at the same time this is
|
|
|
|
-- running. With the lock pool empty, anything that attempts
|
|
|
|
-- to take a lock will block, avoiding that race.
|
2015-05-20 03:35:24 +00:00
|
|
|
getLockStatus :: LockPool -> LockFile -> IO v -> IO v -> IO v
|
2015-05-18 18:16:49 +00:00
|
|
|
getLockStatus pool file getdefault checker = do
|
|
|
|
v <- atomically $ do
|
|
|
|
m <- takeTMVar pool
|
|
|
|
let threadlocked = case M.lookup file m of
|
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
|
|
|
Just (LockStatus _ n _) | n > 0 -> True
|
2015-05-18 18:16:49 +00:00
|
|
|
_ -> False
|
|
|
|
if threadlocked
|
|
|
|
then do
|
|
|
|
putTMVar pool m
|
|
|
|
return Nothing
|
|
|
|
else return $ Just $ atomically $ putTMVar pool m
|
|
|
|
case v of
|
2015-05-20 03:35:24 +00:00
|
|
|
Nothing -> getdefault
|
2015-05-18 18:16:49 +00:00
|
|
|
Just restore -> bracket_ (return ()) restore checker
|
|
|
|
|
|
|
|
-- Only runs action to close underlying lock file when this is the last
|
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
|
|
|
-- user of the lock, and when the lock has not already been closed.
|
2015-05-18 18:16:49 +00:00
|
|
|
--
|
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
|
|
|
-- Note that the lock pool is left empty while the CloseLockFile action
|
2015-05-18 18:16:49 +00:00
|
|
|
-- is run, to avoid race with another thread trying to open the same lock
|
|
|
|
-- file.
|
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
|
|
|
releaseLock :: LockHandle -> IO ()
|
|
|
|
releaseLock h = go =<< atomically (tryTakeTMVar h)
|
2015-05-18 18:16:49 +00:00
|
|
|
where
|
|
|
|
go (Just (pool, file)) = do
|
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
|
|
|
(m, closelockfile) <- atomically $ do
|
2015-05-18 18:16:49 +00:00
|
|
|
m <- takeTMVar pool
|
|
|
|
return $ case M.lookup file m of
|
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
|
|
|
Just (LockStatus mode n closelockfile)
|
|
|
|
| n == 1 -> (M.delete file m, closelockfile)
|
2015-05-18 18:16:49 +00:00
|
|
|
| otherwise ->
|
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
|
|
|
(M.insert file (LockStatus mode (pred n) closelockfile) m, noop)
|
|
|
|
Nothing -> (m, noop)
|
|
|
|
closelockfile
|
2015-05-18 18:16:49 +00:00
|
|
|
atomically $ putTMVar pool m
|
|
|
|
-- The LockHandle was already closed.
|
|
|
|
go Nothing = return ()
|