blob: 81afb263b531c963097ba2da85d6d12d07c033a8 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
|
Plan is to be on vacation and/or low activity this week before DebConf.
However, today I got involved in fixing a bug that caused the assistant to
keep files open after syncing with repositories on removable media.
Part of that bug involved lock files not being opend close-on-exec, and
while fixing that I noticed again that the locking code was scattered all
around and rather repetitive. That led to a lot of refactoring, which is
always fun when it involves scary locking code. Thanks goodness for
referential transparency.
Now there's a Utility.LockFile that works on both POSIX and Windows.
Howver, that module actually exports very different functions for the two.
While it might be tempting to try to do a portability layer, the
two locking models are really very different, and there are lots of gotchas
such a portability layer would face. The only API that's completely the
same between the two is dropLock.
This refactoring process and the cleaner, more expressive
code it led to helped me spot a couple of bugs involving locking. See
[[!commit e386e26ef207db742da6d406183ab851571047ff]]
and [[!commit 0a4d301051e4933661b7b0a0791afa95bfe9a1d3]]
Neither bug has ever seemed to cause
a problem, but it's nice to be able to spot and fix such bugs before they
do.
|
