lock pools to work around non-concurrency/composition safety of POSIX fcntl

1 files changed, 36 insertions, 0 deletions

diff --git a/Utility/LockPool.hs b/Utility/LockPool.hs
new file mode 100644
index 000000000..2a4ac5101
--- /dev/null
+++ b/Utility/LockPool.hs
@@ -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