Re: best practices: c-ares vs threaded resolver
Date: Wed, 18 Sep 2013 01:49:15 -0400 (EDT)
On Tue, 17 Sep 2013, Daniel Stenberg wrote:
> On Mon, 16 Sep 2013, m brandenberg wrote:
>> * General unreliability on platforms with DNS timeouts on all
>> three platforms.
> This sounds like a bug, in either c-ares or libcurl.
Possibly. But it could also be multiple causes. The
problem in these scenarios is that it is the result of the
local environment. I have very little success reproducing
these in the development environment.
>> * OS X is having trouble keeping /etc/resolv.conf valid. Either
>> the symlink is damaged or the target (/var/run/resolv.conf)
>> isn't being regenerated reliably on network reconfigurations.
>> Result is a broken server list in c-ares.
> This sounds like a broken OS X or that c-ares needs to get its list of
> servers differently.
Both, I think. But using the native system to extract server
information while supporting multiple OS versions leaves you
chasing changes. Like the transition away from NetInfo in
the case of OSX.
>> * Magical failures.
> More c-ares bugs?
No, environment, I think, and c-ares is the victim. As the
main OSs have acquired deeper networking functions and things
like anti-viruses and firewalls keep adding new features to
attract users, surprising behaviors are coming out of the
>> But looking at the implementation of the threaded resolver makes me ask a
>> few questions. It's a thread-per-request scheme. Good for avoiding a
>> stall behind a request that will timeout or be answered slowly. But this
>> makes unbounded demands on thread count.
> Yes. Of course that could be modified/improved but it would also make things
> more complicated and you'd also get problems with one slow resolve hogging
> the other subsequent resolves if you just use a queue in a single resolver
Yep, I am thinking of an optional something in between "one or all".
Parameter on a multi limiting the number of outstanding requests
or an EAGAIN-like status between libcurl and the c-ares/TR api.
*If* it is a problem in practice. I wonder if anyone has seen
a problem with the threaded resolver in the field.
>> The c-ares we're using *is* old, 1.7.1, and that will get bumped up but
>> maybe it's time to change.
> Some of your problems may have been fixed since that version. Development may
> be slow in c-ares but there are like 8 releases done since that version.
Yeah, I will likely roll forward anyway. The test cycle is
sadly slow and unreliable for this set of problems...
-- Monty Brandenberg ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.htmlReceived on 2013-09-18