[Dovecot] pop3_lock_session question

[Timo Sirainen]

On Wed, 2009-02-04 at 14:51 -0500, Alan Ferrency wrote:
> One problem which might be making this worse than it needs to be, is
> the fact that mbox_lock_flock in mbox-lock.c is not using a blocking
> flock(); instead, it's polling for a non-blocking lock.  This technique
> can cause lock starvation, if another process is dropping the lock and
> picking it back up again frequently: other processes will only see the
> lock as being available if they happen to poll for the lock at just
> the right instant.
> 
> A better technique to use here, if it's adequately cross-platform,
> would be to set an alarm() for the max_wait_time, and use a blocking
> flock().  If the alarm times out and you don't have a lock, it's a
> timeout.  In the meantime, you're guaranteed to eventually get the
> lock, if it is dropped.

That's what Dovecot does elsewhere. I don't really know why I'm using
non-blocking flock() calls. I guess I should fix that.

> That said: I'm not sure whether this will solve our problem in
> practice.

Probably not.

> Why doesn't this happen with imap?  Why can't we make pop3 do what
> imap does?  Even if it's inefficient, it's better than hanging all
> incoming mail delivery while deliver eats up our local concurrency
> limits.

IMAP unlocks mbox after each command is done. But POP3 clients typically
just run RETR, RETR, RETR, .. so unlocking + locking again later is just
extra work that slows things down. I guess there could be a timeout that
if no RETR has been run for a few seconds it unlocks the mailbox.

But I've never before heard POP3 clients behaving that way, so I'd like
to know what exactly are they doing. Are they not sending anything? Are
they NOOPing? I don't see any reason for them to be doing either..
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://dovecot.org/pipermail/dovecot/attachments/20090204/72a73a5f/attachment.bin