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
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 ?
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 ?
- 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@pasteur.fr | Pôle informatique - systèmes et réseau