Locking Policy

[Bron Gondwana]

I have a question about Cyrus locking policy - I know there are
comments about violating it:

 /* Note that we are locking the mailbox here.  Technically, this function
  * can be called with a lock on the mailbox list.  This would otherwise
  * violate the locking semantics, but it is okay since the mailbox list
  * changes have not been committed, and the mailbox we create here *can't*
  * be opened by anyone else */

...

 /* if it is not a remote mailbox, we need to unlock the mailbox list,
  * lock the mailbox, and re-lock the mailboxes list */
 /* we must do this to obey our locking rules */

...

So from these I deduce that you can't lock a mailbox with the
mailboxes.db locked.  Fair enough, ordering constraints to avoid
deadlocks.

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).

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.

Basically, if you need to rewrite or change ANYTHING in the
mailbox, you'd just lock the header and go ahead and change
the other files.  Obviously there's a tiny crash window
(one file renamed, the other not) so you still need to check
for cache file version mismatches, but the sane response is
to rebuild the cache file from scratch.

Bron ( but then I'm crazy enough that I want to write "intent
       log" files somewhere before doing anything that gets
       sync logged, so after a crash/shutdown we can cat all
       the individual pid intent logs into sync_client and
       make sure all the folders of interest get re-synced )