On Thu, 29 Oct 2009, John Engelhart wrote:
> And, hypothetically speaking, if someone were to re-work the code, could you
> provide feedback on whether or not the new code "works"?
Of course! I certainly wouldn't mind seeing a cleanup and improved time-out
code, and of course I'd review and test patches.
> Personally, my $0.02, regardless of any of the above or possible bugs, I
> think it'd be a smart move to tweak the logic in ares_timeout() to return a
> "minimum" timeval on at least the order of 1000 micoseconds / 1 millisecond,
> even if the loop scan returned a value less than this (and in particular the
> current 0+0). This minimum timeval would obviously be compared against any
> "max" timeval passed in, the lesser of the two would be the final result. It
> just seems like a good idea to not hand back a timeval of 0+0 unless you
> have a very, very good reason, particularly for time outs on the "main" work
> loop path.
I'm still not completely convinced about us needing to do that. Let's say you
have a case where you throw away MANY queries almost simultaneously, and then
after a while N of them timeout. With N being 10, 100 or 1000. If we
deliverately delay the timeout to 1ms, it could take up to a second to go over
and do the timeout actions.
Your 0+0 case is problematic only if it *repeatedly* returns 0 so that the
program goes into a busy-loop and that is the problem: the repeated returns of
"run now", not the "run now" when it happens only once. And repeated
(unfounded) such returns is a sign of a bug, not an expected behavior.
-- / daniel.haxx.seReceived on 2009-10-29