lock pools to work around non-concurrency/composition safety of POSIX fcntl
This commit is contained in:
parent
af6b313456
commit
6915b71c57
8 changed files with 327 additions and 12 deletions
36
Utility/LockPool.hs
Normal file
36
Utility/LockPool.hs
Normal file
|
@ -0,0 +1,36 @@
|
|||
{- Lock pool.
|
||||
-
|
||||
- This avoids a problem with unix fcntl locks: They are not composition-safe.
|
||||
-
|
||||
- For example, if one thread is holding a lock, and another thread opens the
|
||||
- lock file (to attempt to take or check the lock), and then closes it,
|
||||
- the lock will be released, despite the first thread still having the
|
||||
- lockfile open.
|
||||
-
|
||||
- Or, if a process is already holding an exclusive lock on a file, an
|
||||
- re-opens it and tries to take another exclusive lock, it won't block
|
||||
- on the first lock.
|
||||
-
|
||||
- To avoid these problems, this implements a lock pool. This keeps track
|
||||
- of which lock files are being used by the process, and avoids
|
||||
- re-opening them. Instead, if a lockfile is in use by the current
|
||||
- process, STM is used to handle further concurrent uses of that lock
|
||||
- file.
|
||||
-
|
||||
- Note that, like Utility.LockFile, this does *not* attempt to be a
|
||||
- portability shim; the native locking of the OS is used.
|
||||
-
|
||||
- Copyright 2015 Joey Hess <id@joeyh.name>
|
||||
-
|
||||
- License: BSD-2-clause
|
||||
-}
|
||||
|
||||
{-# LANGUAGE CPP #-}
|
||||
|
||||
module Utility.LockPool (module X) where
|
||||
|
||||
#ifndef mingw32_HOST_OS
|
||||
import Utility.LockPool.Posix as X
|
||||
#else
|
||||
import Utility.LockPool.Windows as X
|
||||
#endif
|
Loading…
Add table
Add a link
Reference in a new issue