On Thu, 2 Dec 2004, Michael Haardt wrote:
> See? Exim is real great software, works far beyond what you thought
> it could do and there is potential to move even further. :-)
What can I say? I'm amazed.
> The current model is one extreme: A hoard of uncoordinated queue runners,
> each spawning one delivery at a time. A central queue runner is the other.
> I suggest something in between: Give a queue runner the option to spawn
> more than one delivery at a time. There could still be multiple queue
> runners, e.g. one per directory for split spools. That way you make use
> of simultaneous IO capacity, as resulting from RAIDs, when traversing the
> queue.
Well, I'm still not convinced that you will gain very much by running
one queue runner that does two deliveries at once compared with two
queue runners that do one delivery at once. But I'm always ready to be
proved wrong... However, there is no chance of my implementing anything
like that in the near future.
> The historical reason of a broken central queue manager is of course a
> good reason never wanting to see that again. Qmail, on the other side,
> shows a very well working, very stable central queue manager that does
> work on files.
Oh, I'm not saying it can't be done. I'm just saying that I wouldn't
want to do it! I go for the easy approach, where the consequences of
my mistakes are less serious. :-)
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book: http://www.uit.co.uk/exim-book
