Here's a patch to fix the behavior of cURL informing c-ares correctly about network events. In the case of a POLLERR, we basically pretend it is an event that triggers both watches for POLLIN or POLLOUT. For POLLHUP, we treat it like a POLLIN. As far as ares_process_fd is concerned, it only wants to know about 'input' and 'output' on these FDs, so we can conform to it using the above formula.

It works for me - not sure if you find this appropriate.

-Josh

-----Original Message-----
From: curl-library-bounces_at_cool.haxx.se [mailto:curl-library-bounces_at_cool.haxx.se] On Behalf Of Daniel Stenberg
Sent: Monday, August 03, 2009 4:39 AM
To: libcurl development
Subject: Re: More questions about ares behavior

On Wed, 29 Jul 2009, Joshua Kwan wrote:

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

As you can see in the beginning of the lib/transferl.c:Curl_readwrite()
function it calls Curl_socket_ready() to figure out what the socket is ready
for, and that function returns a bitmask. It seems however that the check of
what is returned does a "if(select_res == CURL_CSELECT_ERR) {" and I now guess
that in your case the ERR is set together with some other bits?

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

I took care of it. Thanks!

-- 
  / daniel.haxx.se