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

This commit is contained in:
Joey Hess 2015-05-18 14:16:49 -04:00
parent af6b313456
commit 6915b71c57
8 changed files with 327 additions and 12 deletions

36
Utility/LockPool.hs Normal file
View 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