This is related to #2975, but it's not exactly the same issue.
When configured to use c-ares as the DNS resolver, and a handle is still waiting for DNS resolution (such as when the DNS server is unreachable), the curl_multi_remove_handle() call can block until that DNS request times out.
This behaviour appears to have been introduced as part of ac9a179.
I understand that it might not be possible to cancel an in-progress DNS request with all resolver backends without blocking. It does seem like it should be possible to cancel an in-progress c-ares DNS request without blocking.
Changing the multi_done() call of Curl_resolver_wait_resolv() to Curl_resolver_cancel() seems to work, but I'm not familiar enough with the details of resolver management inside cURL (especially for other resolver backends) to know if this is correct or "safe" in all cases. Based on the discussion in #2975, it sounds like the threaded resolver must join with the thread.
Perhaps Curl_resolver_cancel() should take a flag that says whether it must not return until all resources are freed. The c-ares resolver could then simply ignore the flag since has nothing special to do, then clean up and return quickly, while the threaded resolver could block until it has joined with the thread.
(BTW, it looks like there is at least one case where Curl_resolver_cancel() is called when it "shouldn't" wait, in conn_free(), but I'm not sure how the threaded resolver's threads get cleaned up in that case.)
This is related to #2975, but it's not exactly the same issue.
When configured to use c-ares as the DNS resolver, and a handle is still waiting for DNS resolution (such as when the DNS server is unreachable), the
curl_multi_remove_handle()call can block until that DNS request times out.This behaviour appears to have been introduced as part of ac9a179.
I understand that it might not be possible to cancel an in-progress DNS request with all resolver backends without blocking. It does seem like it should be possible to cancel an in-progress c-ares DNS request without blocking.
Changing the
multi_done()call ofCurl_resolver_wait_resolv()toCurl_resolver_cancel()seems to work, but I'm not familiar enough with the details of resolver management inside cURL (especially for other resolver backends) to know if this is correct or "safe" in all cases. Based on the discussion in #2975, it sounds like the threaded resolver must join with the thread.Perhaps
Curl_resolver_cancel()should take a flag that says whether it must not return until all resources are freed. The c-ares resolver could then simply ignore the flag since has nothing special to do, then clean up and return quickly, while the threaded resolver could block until it has joined with the thread.(BTW, it looks like there is at least one case where
Curl_resolver_cancel()is called when it "shouldn't" wait, inconn_free(), but I'm not sure how the threaded resolver's threads get cleaned up in that case.)