On 7/29/09 03:04, "Daniel Stenberg" <daniel_at_haxx.se> wrote:
> 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...)

Understood. This appears to be a libcurl problem though, as you say.

> 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.

The key is in ev_bitmask. There's a 1:1 relationship between the flags you
can OR into ev_bitmask and those returned by poll(2).

However, due to an infrastructural issue, we pass in 0 for ev_bitmask right
now. curl_multi_socket_action's documentation says that if we do this, it
will figure out the events on the socket by calling Curl_poll (based on my
analysis of the source.) Shouldn't this also return 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.

Sure.

Offtopic: Should I resubmit my other patch for c-ares to the c-ares
mailinglist, or can you take it from here? Is the patch sane?

Thanks.
-Josh
Received on 2009-07-29