[Dovecot] mbox locking

[Thomas Hummel]

On Tue, Jun 27, 2006 at 03:58:28PM +0300, Timo Sirainen wrote:

Thanks Timo,

Those questions are because I had some issues (with 0.9x which I know
isn't maintained anymore) with dead process ('D' flag in BSD ps) and
fcntl locks that wouldn't go (unless of course I'd reboot or change
the mbox inode). I'm testing each 1.0beta since I don't want to invest
effort in 0.9x and would like to have some clear understanding of mbox
locking strategy in case some similar issue arrise and to be able to
choose the best locking strategy.

So, one more thing :

"mbox_read_locks" defaults to fcntl and
"mbox_write_locks" defaults to dotlock fcntl

1. Doesn't this assume that non-dovecot programs do use fcntl (maybe
  among additional methods) ? In that case, why wouldn't you assume the
  same for writes and default mbox_write_locks to fcntl only ?

2. Obviously, fcntl in write_locks should be exclusive, but is the
lock set by fcntl in mbox_read_lock exclusive or shared ?

In other words, do you separate read and write locks :

  . to allow multiple simultneous reads taking the risk to read
    inconsitent data (if so how do you recognize the situation to re-read
    the mbox) ?

  . or because there are moments in a write "session" when the write
    dotlock is set (but the write fcntl not set yet) and reads are still
    allowed (because of your writing strategy) ?

Note : 

in the second case, the multiple methods for write_locks would have 2
different reasons : to share a locking method with foreign programs
and to have a fine grain write locking method inside dovecot.

Also should a mbox read block a mbox write ? Or should a UA trying to
get a lock to read a mbox block or just return, sleep a try a bit
later ?

3. when, as written on the Wiki procmail -v reports 

 dotlocking, fcntl(), lockf(), flock()

does it mean that he uses both dotlocking and fcntl (like dovecot) or
one *or* the other ?

-- 
Thomas Hummel 	    | Institut Pasteur
<hummel at pasteur.fr> | Pôle informatique - systèmes et réseau