On Tue, 10 Oct 2006, Jeff Pohlmeyer wrote:

> Yes, that makes sense. I applied your patch and it seems to work fine. I'm
> still getting the stalling problem, but the changes don't seem to affect it
> one way or the other, so at least we haven't done any harm.
>
> Looking a little deeper at the stalling stalling problem, it looks like
> libevent event is just calling epoll_wait repeatedly, always getting 0, but
> when I stuff in another URL, everything kicks back into gear, and the
> pending transfers immediately return "(28) Connection time-out"
>
> The problem only occurs with ares, using regular DNS everything works fine,
> just a lot slower.

Some further thoughts on this problem:

Since it can continue and seems to kick back into gear when new URLs are
added, it feels like it is just a case of the proper socket set (or even
socket mode) not being reported correctly to the app using the socket
callback.

I think we need to add a debug function to libcurl to "dump" all sockets it
currently expects traffic for in/out, and then make a similar for the
application so that we at any given moment can display both and check for
deviations.

If the two "socket dumps" don't differ, the problem is even deeper in libcurl
that it doesn't "catch" the sockets as it should, in the functions that deals
with that stuff.

The fact that the problem only has been seen when using c-ares of course
indicates that libcurl somehow doesn't get the sockets from c-ares properly,
which could imply a bug in c-ares. Perhaps I'll start with carefully reading
the code for this stuff in c-ares and libcurl to see if I can detect any
problems.

I think I'll commit the timer callback work first, since it is a good idea to
have and it shouldn't make the problem worse.

Just to be sure: you build libcurl with a c-ares from CVS, don't you? The
latest released c-ares (1.3.1) has a fatal flaw in ares_getsock() that could
screw up libcurl's socket API badly.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html