On Mon, 6 Dec 2004, Michael Haardt wrote:
> As I see it, the queue runner parent keeps a pipe open, because its
> child terminates without waiting for grandchildren it spawns before right
> before terminating. If it would not fork grandchildren, but exec them,
> the parent would still wait for the same process, thus not needing a pipe.
>
> But I am probably missing something in this picture.
You are! :-) The spawning is not necessarily "right before terminating".
Suppose an email is addressed to two recipients, A and B, on different
mail servers. When Exim has delivered to A, it notices that there is
another email that previously could not get through to A. So it forks a
new process and hands over the connection to it. Now it goes on and
delivers to B. Waiting for the B delivery to happen is a bad idea,
because you are holding the SMTP connection to A open. And anyway, there
may also be C and D and E...
A more "sophisticated" design would be able to deliver the other waiting
messages from the existing process, but Exim is not sophisticated in
this way.
> That optimisation does not solve my problem of too few simultaneous
> deliveries, but it may reduce the time for a queue run in total by
> a great amount. I thought about it as well, but abandoned the idea so
> far, because it effectively introduces messages based retry time.
Sort of partially, I suppose. If the host comes back up again, the
message won't be looked at as early as it otherwise would (but you might
hope that it would get delivered down an existing channel). It is
certainly an added complication that would be hard to describe.
> If you reduce the retry time for a host or domain, existing messages
> will not be delivered, because it does not change the existing
> earliest retry times.
But that is true already. If you reduce the retry time for a host, it
does not affect the existing hints data, which includes the next time to
try that host.
Philip
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
