On Thu, Oct 29, 2009 at 4:32 AM, Daniel Stenberg <daniel_at_haxx.se> wrote:
> 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.
>
I found the bug. It looks like it was a misunderstanding on my part. The
short version is my loop did something like:
if((selectResult = select(...)) > 0) { ares_process(...); }
In other words, ares_process() would only be called if there was data to be
processed. The example code from ares_process():
int nfds, count;
fd_set readers, writers;
struct timeval tv, *tvp;
while (1)
{
FD_ZERO(&readers);
FD_ZERO(&writers);
nfds = ares_fds(channel, &readers, &writers);
if (nfds == 0)
break;
tvp = ares_timeout(channel, NULL, &tv);
count = select(nfds, &readers, &writers, NULL, tvp);
ares_process(channel, &readers, &writers);
}
This is really only good for "one-shot" lookups. For whatever reason, I
obviously thought that ares_process() was meant to be called when there was
data available. The detail that it needed to be called to "do stuff" even
when ares_fds() returns 0 and select() says there's nothing waiting "slipped
by." I'd suggest adding to the documentation an example work loop geared
towards "long running applications", such as one where a background thread
is ticked off to just process ares_* stuff.
Received on 2009-10-30