On 26 May 1999 michael@??? wrote:
> alarm(300) = 300
> alarm(300) = 300
>
> Calling alarm this often does not look correct to me. I doubt this
> causes my problems, but it is odd in itself.
300s = 5 minutes, the SMTP incoming timeout. This timeout applies to
each line of input, so yes, alarm will get called rather a lot for a big
message. Hmm. In Exim 3.00 the way that input is handled has been
revised, and it would now be possible to be more clever about this. I
have made a note to improve matters.
> Why does exim kill the process instead of waiting for it to die? The
> sleep probably reduces throughput very much.
An exim queue-runner is supposed to do serial delivery, one message at a
time. If it starts up a process that delivers down an SMTP channel, and
that process hands the open channel on to a 3rd process and then exits,
the queue runner must not continue until the 3rd process has finished.
Otherwise you get an explosion of processes that you don't want. The
queue runner gets a list of newly spawned processes. It waits for each
one by sending the process SIGHUP to see if it still exists, and if it
does, waits a bit and tries again. Unfortunately, 1 second is the
shortest sleep there is.
The 3rd process is not the queue runner's own child, so it can't wait
for it directly. Or can it? Perhaps some Unix guru will be able to tell
me I am being silly here. Is there a better way of handling this?
In general:
Process A creates process B; process B creates process C and exits;
process C creates process D and exits, .... to some number of
processes. Process A wants to wait until all the descendents have
completed. It can get the list of process ids (by reading a file).
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
--
*** Exim information can be found at
http://www.exim.org/ ***
