Victor Duchovni:
> On Mon, Jun 08, 2009 at 04:23:57PM -0400, Wietse Venema wrote:
>
> > Victor Duchovni:
> > > On Mon, Jun 08, 2009 at 03:15:22PM -0400, Wietse Venema wrote:
> > >
> > > > > Mind you, the expected number of transports for a message is I think
> > > > > reasonably small.
> > > >
> > > > I see one hash table that is indexed by the queue ID, so this
> > > > would involve one hash-table lookup per transport:
> > >
> > > Not sure what "this" is referring to above.
> >
> > To avoid opening the same queue file more than once. That requires
> > a hash lookup by queue file name. I could use the same hash that
> > I was contemplating for an experiment where I elimimate the need
> > for the on-disk active queue. That would shave off one rename
> > operation, or two directory updates and three inode updates.
>
> Ah, yes, if we want to skip "hot" files already in the active queue,
> we could loop over the transports looking for match, as the message
> will already be in one of the hashes.
>
> I am a bit concerned about traversing every transport hash table for
> each new message, is this cheap enough?
I wasn't thinking of multiple hash table lookups.
> We could instead avoid the problematic per-transport queue-id->job hashes,
> and allow "nqmgr" to tolerate multiple instances of the queue file,
> just like "oqmgr".
And knowingly write code that can deliver mail twice?
Wietse
