Hi, we recently had a problem with libcurl: due to a DNS server problem, an attempt to cancel a libcurl request blocked the whole I/O event loop of a server process because libcurl was waiting for the resolver thread to finish (inside pthread_join()), causing a major outage of a service. We use Debian, and Debian's libcurl build uses the threaded resolver and not c-ares, and I learned that the threaded resolver cannot be canceled at all. CURLOPT_QUICK_EXIT is not usable, because this is a long-running server process.
My idea to work around this is to first let our daemon resolve with systemd-resolved (which is easy to use and cancellable) and then use CURLOPT_CONNECT_TO to prevent libcurl from using its own resolver. We already use systemd-resolved extensively and we have a non-blocking/cancellable client for it. For the long term, I was wondering whether libcurl would be interested in incorporating a systemd-resolved mode if I were to submit a pull request. It should be possible to switch this on at runtime, or else distributions won't enable it in their builds and the code will never be used by anybody. There could be an option to auto-detect at runtime whether resolved is available and fall back to the threaded resolver if not; though some users might prefer to never use resolved even if it is available because using it will ignore /etc/nsswitch.conf. What's your opinion on such a feature for libcurl? Max -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
