On Sun, Dec 18, 2011 at 11:53 PM, Daniel Stenberg <daniel_at_haxx.se> wrote:
> On Sun, 18 Dec 2011, Pedro Larroy wrote:
>
>> (lib/asyn-ares.c:288)
>
>
>> My interpretation is that there's this poll call waiting for the dns query
>> to finish in the ares_channel associated with the current curl_handle thus:
>
>
> But that's not right. At least that's not how it is meant to work.
>
> When the multi interface function is called due to activity on a socket and
> the multi handle's internal state is in CURLM_STATE_CONNECT then it will
> call the funtions that then trickles down to a call to
> lib/asyn-ares.c:waitperform(). The handle should then move on to the
> CURLM_STATE_WAITRESOLVE state if the resolve didn't immediately happen.
>
> As you can see, it calls the function with a timeout of 0. It is just a
> single-time check if there's anything to do, and it then returns all the way
> back to your application. It is not a block.
>
>
>>  * It will block the whole program until the current dns reply is
>> recieved, which goes against the paradigm of the multi interface usage
>> with asynchronous IO.
>
>
> Why would it? It checks with a timeout of 0, that means it returns
> immediately.
>
>
>>  * If that wasn't bad enough, the select has a timeout of 0.
>
>
> Why is that bad? It means it won't block!

You are completely right about the timeout.

I discovered I was accidentaly linking with -lcurl in addition to the
libcurl.a compiled with c-ares support so maybe the degradation was
due to the system libcurl which is not using c-ares. So I'd have yet
to confirm that the degradation will happen with libcurl compiled with
c-ares. In light of your clarifications it should not happen.

Many thanks for your input.

Pedro.

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2011-12-19