On Mon, 2006-06-26 at 18:03 +0200, Thomas Hummel wrote:
Hello,
I'd like to make sure my understanding of the mbox locking strategy is correct :
"mbox_dotlock_change_timeout" directive :
a process seeing that an already locked (by another process) mbox he want to access hasn't change for this amount of time, allows himself to override the lock ?
Right. It checks that both the mbox and the dotlock file hasn't changed.
If it's using fcntl, is it only possible to override ?
fcntl locks aren't ever overridden, since it means the process still exists. And there isn't really any way to override them either.
- when a process abort trying to get a lock after mbox_lock_timeout, does the UA sees anything ?
Yes, it should see "Timeout while waiting for lock" error. But it depends on the client if it shows it to the user.
multiple locking methods in "mbox_write_lock" :
if I state, for instance,
mbox_write_locks = dotlock fcntl
when does exactly dotlock method get used and when does fcntl get used ? Are both used simultaneously ?
It uses both. First dotlock, then fcntl.
Which leads to the wiki's deadlock situation example :
# Program A: fcntl locks the mbox # Program B at the same time: dotlocks the mbox # Program A continues: tries to dotlock the mbox, but since it's already dotlocked by B, it starts waiting # Program B continues: tries to fcntl lock the, but since it's already fcntl locked by A, it starts waiting
Right. That's why the ordering must be correct.
why would A dotlock the mbox since he did fcntl'ed it successfully ? if he's able to perform fcntl, he can use a shared or an exclusive lock : why use dotlock at all ?
Because it's not guaranteed that all programs use the same locking methods. If Dovecot uses only fcntl and another program uses only dotlock, there's practically no locking at all in that case.