mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

Fix shared lock file FD leak.

Browse source 
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.
This commit is contained in:
Joey Hess 2016-03-01 15:31:39 -04:00
parent 26c499492f
commit 3334130368
Failed to extract signature
7 changed files with 88 additions and 64 deletions
Download patch file Download diff file Expand all files Collapse all files

8
Utility/LockPool.hs
View file

@ -7,15 +7,13 @@
- 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
- Or, if a process is already holding an exclusive lock on a file, and
- 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.
- of which lock files are being used by the process, using STM to handle
- inter-process locking.
-
- Note that, like Utility.LockFile, this does *not* attempt to be a
- portability shim; the native locking of the OS is used.