On Tue, 28 Jul 2009, Joshua Kwan wrote:

> More of me complaining about c-ares! :)

Please do note that c-ares is a separate project with its own mailing list,
so if you really go off with problems inside c-ares as opposed to libcurl,
that's a better place to bark. (And yeah I'm kind of the maintainer of c-ares
as well...)

> We have a Glib-style event loop implementation into which the multi API is
> hooked. Presumably due to the network disconnection, polling on the FD
> responsible for name resolution is in a 'POLLERR' state (indicating some
> error with the socket.) We call curl_multi_socket_action to indicate this
> error to libcurl. However, libcurl does not appear to ask us to remove the
> FD from the poll loop.

What action do you tell curl_multi_socket_action() there is on the socket? I
figure we would basically need an "error" action that could let libcurl treat
it as bad and act on it, but as I remember things we don't atm.

> Why isn't c-ares causing the DNS socket to expire because of the POLLERR
> state?

I don't think this is a problem with c-ares, but simply how libcurl deals with
the socket and handles c-ares.

-- 
  / daniel.haxx.se