Re: [exim] Small modification for queue runners?

> Thanks for the idea, but I am not convinced that it would improve
> performance much, if at all. After all, how much resource does it take
> to open a file (that is already open by another process), attempt to
> lock it, find that it is already locked, and so move on? That is what
> happens when a queue runner checks a message that is already being
> processed.

If many queue runners are active on a large queue, Exim appears to get
unfair by trying the same messages over and over, whereas others sit
on the queue untouched. A central queue runner that spawns multiple
deliveries would coordinate the delivery attempts, thus introducing
more fairness.

> Actually, what I have written is not the whole truth. Exim creates a >
subprocess in which those tests take place. I suppose some resource >
could be saved by doing the test before creating the subprocess

Queue runners would get way more efficient if they tried to obtain locks
before forking, but the unfairness issue is still there.

> I don't think having a queue runner deliver n messages at once makes any
> difference - for each message you still have to test whether some other
> Exim process is working on it. Meanwhile, you have added considerable >
complication to the queue runner code.

Yes, the lock can not be avoided that way, but hitting an already locked
message will get a rare exception, even with large queues.

Michael