duplicate elimination is inconsistent

[Henrique de Moraes Holschuh]

On Fri, 26 Aug 2005, Jules Agee wrote:
> from what I understand it's not easy to fix this without creating
> performance problems.

Actually, it should be easy (but NOT trivial) as long as you do it on memory
only.  Maybe it could even be used to help syncronize the seen state (to
give us a no-performance-loss outcrook fix), and to promote idled-like
functionality to a safe default.

You add a hashed table in a shared-memory pool to keep all the state you
want to track globally, and make the services look syncronizing state for a
mailbox there first, and take the performance-hungry syncronizing path only
if it is set.  It requires proper atomic semasphores and real shared memory
to work, though.

Of course, only volatile state must be kept in such a table.

For what you want, one would store in the table a semaphore (hash key is the
message-id) that warns other lmtpds when one is doing a delivery database
update for a given mailbox, and use it as a spinlock IF doing duplicate
suppression (in fact, since the flag implies that the message HAS been seen,
instead of spinning, just duplicate-suppress it immediately).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh