dpc22 at cam.ac.uk
Sat Mar 28 09:40:03 EDT 2009
On Sat, 28 Mar 2009, Bron Gondwana wrote:
> What I'm wondering is what other locking constraints are actually
> codified? I couldn't find anything about them grepping the doc
> tree for obvious phrases (like... locking).
The only documentation that I've found is doc/internal/locking, which is
rather, um, minimal.
> It seems to me that a whole lot more locking should be happening on the
> header file, which along with strict ordering of locks and the removal
> of ACLs from the header file (we don't use them anyway) would mean we
> never get stupid issues like .index and .cache files being out of sync
> and needing the dodgy "sleep a second and see if the version numbers
> match" logic.
At the moment we need exclusive locks on two files as cyrus.header and
cyrus.index are both updated using a .NEW temporary file and a rename(),
which breaks the lock. Life would be much simpler if Unix provided a
primitive to both open and lock a file as a single atomic action.
I agree that a dedicated .lock file (which might be the header file if we
can move out the variable state) would be more elegant. We do however need
somewhere to store the mailbox UIDvalidity, user flag names and ACL, all
of which can change. UIDvalidity and flags names are critical, and the
user flag names can get quite large given 128 user flags. ACLs are less
critical, but I do like having a redundant copy of the ACL somewhere just
in case I ever needed to reconstruct mailboxes.db from scratch sometime.
The exclusive POP lock on cyrus.cache is an additional complication, but
that is off to one side and seems to work reasonably well. (I'm not
entirely convinced that a server which implements delayed expunge actually
needs the exclusive lock, but it is mandated by RFC 1725, section 4).
David Carter Email: David.Carter at ucs.cam.ac.uk
University Computing Service, Phone: (01223) 334502
New Museums Site, Pembroke Street, Fax: (01223) 334679
Cambridge UK. CB2 3QH.
More information about the Cyrus-devel