On Thu, 6 Jul 2017, Daniel Stenberg wrote:

> In today's world I think more users are likely to want the threaded resolver
> backend than the stock synchronous resolver.
>
> Here's my first take at switching the default for the configure script. What
> sort of breakage do you think this will trigger in your end or in builds you
> do?
>
> https://github.com/curl/curl/pull/1647

Probably the right direction, especially for libcurl over the curl
command itself. It's been awhile since I looked at the threaded resolver
but at that time there were a few possible issues:

  * Unbounded demand for resolver threads.
  * No recycling of resolver threads after lookup. Constant create/
    destroy of expensive resource.
  * No 'piggy-backing' of duplicated lookup requests onto a single,
    active resolver library request thus increasing resource demands.

These may have been fixed long ago. Other than that, be wary of using
c-ares on Windows. All the bridging/hi-jacking garbage that is being
put into AV, firewalls, and 'accelerators' can trigger otherwise-sane
anti-poisoning measures in c-ares and break DNS lookup in difficult-to-
diagnose ways. Let the OS take the blame for DNS failures (where it
belongs).

Future rant: that after 30+ years, OSs still use a synchronous model
for DNS lookup in their APIs. (Burn in hell, Berkeley.)

m

--
Monty Brandenberg, Software Engineer                               MCB, Inc.
mcbinc_at_panix.com                                             P.O. Box 425292
mcbinc_at_pobox.com                                   Cambridge, MA  02142-0006
617.864.6907
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html