At 2:15 PM -1000 11/30/01, Clifton Royston wrote: >I have a gut feeling there could be problems which would >result in the mail delivery system (local MTA) from long POP sessions >holding the mail spool lock for too long and causing incoming mail to >back up into the mail queue.
That may be a concern; it depends on how quick the POP session is. POP sessions typically are much shorter than IMAP sessions. > From what I remember there may also be >some threshold or age at which the mail program will typically decide >the lock on the spool is "stale" and will force it. And I think this >is only in the 5 or 10 minute range. (Don't quote me on this...) I believe it's usually five minutes. Programs are supposed to refresh the lock by updating the timestamp (like touch(1)) at least once per minute to avoid a waiter assuming the lock is stale. Qpopper does this currently during spool processing (initialization and cleanup), so if an option were added to keep the spool locked for the duration of the session, a call on Qtouchlock() should be added somewhere convenient, such as the command loop in popper.c. It might be better, but more kludgy, to do this in tgetline(), and additionally ensure that the alarm is set to one minute or less. If the session timeout is larger than a minute, tgetline() can set the alarm for 1-minute intervals (actually, one minute or remaining session timeout seconds, whichever is smaller), refresh the lock, then set a new alarm for min(60, timeout-time_waited). --
