cURL / Mailing Lists / curl-library / Single Mail


Re: blocking on dns resolving

From: Pedro Larroy <>
Date: Mon, 19 Dec 2011 00:36:35 +0100

On Sun, Dec 18, 2011 at 11:53 PM, Daniel Stenberg <> 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.


List admin:
Received on 2011-12-19