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.

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

> * Magical failures.

More c-ares bugs?

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

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

> Has anyone else given both schemes a real-world test in a million-seat
> application?

Not me anyway.

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