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