2015-05-18 18:16:49 +00:00
|
|
|
{- Handles for lock pools.
|
|
|
|
-
|
2020-08-26 17:05:34 +00:00
|
|
|
- Copyright 2015-2020 Joey Hess <id@joeyh.name>
|
2015-05-18 18:16:49 +00:00
|
|
|
-
|
|
|
|
- License: BSD-2-clause
|
|
|
|
-}
|
|
|
|
|
|
|
|
{-# LANGUAGE CPP #-}
|
|
|
|
|
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
|
|
|
module Utility.LockPool.LockHandle (
|
|
|
|
LockHandle,
|
|
|
|
FileLockOps(..),
|
|
|
|
dropLock,
|
|
|
|
#ifndef mingw32_HOST_OS
|
|
|
|
checkSaneLock,
|
|
|
|
#endif
|
|
|
|
makeLockHandle,
|
|
|
|
tryMakeLockHandle,
|
|
|
|
) where
|
2015-05-18 18:16:49 +00:00
|
|
|
|
|
|
|
import qualified Utility.LockPool.STM as P
|
2015-11-12 20:35:15 +00:00
|
|
|
import Utility.LockPool.STM (LockFile)
|
2018-11-19 19:00:24 +00:00
|
|
|
import Utility.DebugLocks
|
2015-05-18 18:16:49 +00:00
|
|
|
|
|
|
|
import Control.Concurrent.STM
|
2020-08-26 17:05:34 +00:00
|
|
|
import Control.Monad.Catch
|
|
|
|
import Control.Monad.IO.Class (liftIO, MonadIO)
|
2016-03-05 19:18:52 +00:00
|
|
|
import Control.Applicative
|
|
|
|
import Prelude
|
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
|
|
|
data LockHandle = LockHandle P.LockHandle FileLockOps
|
2015-11-12 20:28:11 +00:00
|
|
|
|
|
|
|
data FileLockOps = FileLockOps
|
|
|
|
{ fDropLock :: IO ()
|
|
|
|
#ifndef mingw32_HOST_OS
|
2015-11-12 20:35:15 +00:00
|
|
|
, fCheckSaneLock :: LockFile -> IO Bool
|
2015-11-12 20:28:11 +00:00
|
|
|
#endif
|
|
|
|
}
|
2015-05-18 18:16:49 +00:00
|
|
|
|
|
|
|
dropLock :: LockHandle -> IO ()
|
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
|
|
|
dropLock (LockHandle ph _) = P.releaseLock ph
|
2015-05-18 18:16:49 +00:00
|
|
|
|
2015-11-12 20:35:15 +00:00
|
|
|
#ifndef mingw32_HOST_OS
|
|
|
|
checkSaneLock :: LockFile -> LockHandle -> IO Bool
|
|
|
|
checkSaneLock lockfile (LockHandle _ flo) = fCheckSaneLock flo lockfile
|
|
|
|
#endif
|
|
|
|
|
2015-05-18 18:16:49 +00:00
|
|
|
-- Take a lock, by first updating the lock pool, and then taking the file
|
|
|
|
-- lock. If taking the file lock fails for any reason, take care to
|
|
|
|
-- release the lock in the lock pool.
|
2020-08-26 17:05:34 +00:00
|
|
|
makeLockHandle
|
|
|
|
:: (MonadIO m, MonadMask m)
|
|
|
|
=> P.LockPool
|
|
|
|
-> LockFile
|
|
|
|
-> (P.LockPool -> LockFile -> STM P.LockHandle)
|
|
|
|
-> (LockFile -> m FileLockOps)
|
|
|
|
-> m 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
|
|
|
makeLockHandle pool file pa fa = bracketOnError setup cleanup go
|
2015-05-18 18:16:49 +00:00
|
|
|
where
|
2020-08-26 17:05:34 +00:00
|
|
|
setup = debugLocks $ liftIO $ atomically (pa pool file)
|
|
|
|
cleanup ph = debugLocks $ liftIO $ P.releaseLock ph
|
|
|
|
go ph = liftIO . mkLockHandle ph =<< fa file
|
2015-05-18 18:16:49 +00:00
|
|
|
|
2020-08-26 17:05:34 +00:00
|
|
|
tryMakeLockHandle
|
|
|
|
:: (MonadIO m, MonadMask m)
|
|
|
|
=> P.LockPool
|
|
|
|
-> LockFile
|
|
|
|
-> (P.LockPool -> LockFile -> STM (Maybe P.LockHandle))
|
|
|
|
-> (LockFile -> m (Maybe FileLockOps))
|
|
|
|
-> m (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
|
|
|
tryMakeLockHandle pool file pa fa = bracketOnError setup cleanup go
|
2015-05-18 18:16:49 +00:00
|
|
|
where
|
2020-08-26 17:05:34 +00:00
|
|
|
setup = liftIO $ atomically (pa pool file)
|
2015-05-18 18:16:49 +00:00
|
|
|
cleanup Nothing = return ()
|
2020-08-26 17:05:34 +00:00
|
|
|
cleanup (Just ph) = liftIO $ P.releaseLock ph
|
2015-05-18 18:16:49 +00:00
|
|
|
go Nothing = return Nothing
|
|
|
|
go (Just ph) = 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
|
|
|
mfo <- fa file
|
2015-11-12 20:28:11 +00:00
|
|
|
case mfo of
|
2015-05-18 18:16:49 +00:00
|
|
|
Nothing -> do
|
2020-08-26 17:05:34 +00:00
|
|
|
liftIO $ cleanup (Just ph)
|
2015-05-18 18:16:49 +00:00
|
|
|
return Nothing
|
2020-08-26 17:05:34 +00:00
|
|
|
Just fo -> liftIO $ Just <$> mkLockHandle ph fo
|
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
|
|
|
|
2020-07-21 19:30:47 +00:00
|
|
|
mkLockHandle :: P.LockHandle -> FileLockOps -> IO LockHandle
|
|
|
|
mkLockHandle ph fo = do
|
|
|
|
atomically $ P.registerCloseLockFile ph (fDropLock fo)
|
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
|
|
|
return $ LockHandle ph fo
|
|
|
|
|