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.
[email protected] P.O. Box 425292
[email protected] Cambridge, MA 02142-0006
617.864.6907
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
