------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1426
--- Comment #2 from Ian McDonnel;l <ij.exim@???> 2014-05-27 13:50:24 ---
Jeremy,
Thanks for looking at this issue.
Looks like there's some strangeness to the workings of
milliwait(). An open-ended indefinite delay/wait does not seem
useful, unless it is something more subtle, like signal
handling, that wakes the process. Does milliwait() need
fixing too?
For smtp_ratelimit_rcpt, would it not be better to simply skip
the call to milliwait() altogether when the requested/computed
delay is short, say less than 100mS. A very short delay would
just cause unnecessary context switches.
Thanks,
-Ian
On Mon, 26 May 2014 16:13:46 +0100
Jeremy Harris <jgh146exb@???> wrote:
> ------- You are receiving this mail because: -------
> You reported the bug.
>
> http://bugs.exim.org/show_bug.cgi?id=1426
>
>
>
>
> --- Comment #1 from Jeremy Harris <jgh146exb@???>
> 2014-05-26 16:13:45 --- Created an attachment (id=733)
--> (
http://bugs.exim.org/attachment.cgi?id=733)
> --> (http://bugs.exim.org/attachment.cgi?id=733)
> proposed fix
>
> A timer set to zero stops it. Avoid this by never letting
> the microsecods portion be zero, when setting up for a timed
> sleep.
>
>
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
