diff options
-rw-r--r-- | doc/devblog/day_218__scary_locking.mdwn | 24 |
1 files changed, 24 insertions, 0 deletions
diff --git a/doc/devblog/day_218__scary_locking.mdwn b/doc/devblog/day_218__scary_locking.mdwn new file mode 100644 index 000000000..81afb263b --- /dev/null +++ b/doc/devblog/day_218__scary_locking.mdwn @@ -0,0 +1,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. |