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
systems.

>> 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
> thread.

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...

m

--
Monty Brandenberg
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html