On Fri, Nov 24, 2023 at 4:36 PM Max Kellermann via curl-library < curl-library@lists.haxx.se> wrote:
> 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. > resolved is designed to be spoken to as a normal dns caching resolver or using dbus. I don't believe adding a dbus communication backend will improve your situation. I tried several years ago to switch opensuse 's curl to use the c-ares backend , unfortunately it lasted for a brief time until it was reverted due to the world burning down. IIRC a bug was never filled or I missed it so I don't know exactly what broke. What you describe appears to be just a bug that needs analysis..
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
