dovecot - Sep 2010 - recursive locks

How can a dovecot-2 plugin safely use file-locks or file-dotlocks when the
processes into which it plugs handle multiple connections?  (Via, e.g.,
service imap {
  client_limit = N
  service_count = 0
})
Dovecot's file-locks and file-dotlocks do not appear to support
nesting/recursion.

For instance, squat_trie_lock().  Imagine one user is connected to a single imap
process twice.

On Thu, 2010-09-23 at 11:46 -0500, Mike Abbott wrote:
> How can a dovecot-2 plugin safely use file-locks or file-dotlocks when the
processes into which it plugs handle multiple connections?
You can't really. That's why mbox fails at startup if client_limit>1.
Generally the locks are dropped before continuing to handle another
connection.
> Dovecot's file-locks and file-dotlocks do not appear to support
nesting/recursion.
I guess such code could be added, but I'm not sure if it would really
solve anything. It could only fail locking earlier with "lock timed
out"
failure. An alternative would be to do larger changes to code so that
the locking could return "try again soon" and it would actually be
retried rather than a failure given to client.
> For instance, squat_trie_lock().  Imagine one user is connected to a single
imap process twice.
I think this is the only other piece of code besides mbox where this is
a problem. Yeah, something should be done about Squat.. (and not just
for its locking, but the whole thing)