Doing some work on curlgrabber I noticed this in the curl docs: from: http://curl.haxx.se/libcurl/c/curl_easy_setopt.html#CURLOPTNOSIGNAL "If this option is set and libcurl has been built with the standard name resolver, timeouts will not occur while the name resolve takes place. Consider building libcurl with c-ares support to enable asynchronous DNS lookups, which enables nice timeouts for name resolves without signals. " C-ares is in fedora and the license is compatible to curl. Consider rebuilding curl with --enable-ares=/some/path
Good idea. I'll try to build it in rawhide. The only thing I am not 100% sure for now, is the state of IPv6 support in c-ares.
More precisely described here by Daniel Stenberg: http://curl.haxx.se/mail/lib-2009-08/0014.html
Seth, how much does it hurry? We have actually alpha freeze for F-12 now and I am not sure if the timing is optimal for such change. > http://curl.haxx.se/mail/lib-2009-08/0014.html Going through the above mentioned thread you can see there were *some* problems when curl was switched to c-ares in Debian one year ago. But we have no details from Debian maintainers so far.
Kamil, after looking through the problems, I figure holding off is probably a good idea. However, maybe it is worth a try once rawhide opens up for f13. thanks
Built as libcurl-7.19.6-11.fc13.
Kamil, Thanks!
Rebuilding curl against c-ares introduced a lot of bugs (or missing features) that appeared worse than the previous signal handling issues: bug #548269 bug #554305 Long story short, c-ares completely bypasses glibc's NSS (Name Service Switch), which causes curl to ignore system configuration and resolve host names differently than other programs running on the same system. The signal handling issues were later resolved by switching curl to use a threaded DNS resolver, which is now available even in RHEL-7: https://src.fedoraproject.org/rpms/curl/c/438cbdbe