Hey Daniel,

> To further illustrate my vision on a concept for unified asynch resolver
> backends, I offer these two patches on top of Vsevolod Novikov's
> unified_resolver_2.patch.

That looks very cool!

> They're pretty large changes so I'll save them to get merged into master
> after this pending release, and I've only yet tested them out when built
> with c-ares but it shows two asynch resolver backends each implementing the
> single Curl_resolver_* API that is now defined in lib/asyn.h.

I had a question about this change (from patch 0001):

+ if(ARES_EDESTRUCTION == status)
+ /* when this ares handle is getting destroyed, the 'arg' pointer may not
+ be valid so only defer it when we know the 'status' says its fine! */
+ return;
+
+ res = (struct ResolverResults *)conn->async.os_specific;
   res->num_pending--;

- switch(status) {
- case CURL_ASYNC_SUCCESS:
- ares_compound_results(res,Curl_he2ai(hostent, conn->async.port));
- break;
- /* this ares handle is getting destroyed, the 'arg' pointer may not be
- valid! */
- /* conn->magic check instead
- case ARES_EDESTRUCTION:
- return; */
- default:
- break;
+ if(CURL_ASYNC_SUCCESS == status) {
+ Curl_addrinfo *ai = Curl_he2ai(hostent, conn->async.port);
+ if(ai) {
+ compound_results(res, ai);
+ }
   }
- /* The successfull result empties any error */
+ /* A successful result overwrites any previous error */
   if( res->last_status != ARES_SUCCESS )
     res->last_status = status;
 }

It looks like if ARES_EDESTRUCTION == status your change doesn't
update res->num_pending anymore. Is this intended?

Thanks!
Julien
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2011-02-17