On Thu, Oct 29, 2009 at 4:32 AM, Daniel Stenberg <dan...@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.