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.car...@ucs.cam.ac.uk University Computing Service, Phone: (01223) 334502 New Museums Site, Pembroke Street, Fax: (01223) 334679 Cambridge UK. CB2 3QH.
