Ok so the two things that maintainers disliked were
1, performance load because of periodical checks
2, And change of default behavior for toolbox users (which use all kinds
of custom options)
I believe the performance issue is solved by checking just stat of the
file instead of full
It's been 9 years, and frankly I don't remember very well.
https://c-ares.cool.haxx.narkive.com/HQegCCf6/ares-reinit-patch is the archive.
re: when to cancel outstanding requests.
it's a good question to which I don't have an answer.
on one hand, if `resolv.conf` was changed because the device
Hi Dima,
so, you mean that when going from wifi to wifi there might be some
pending request
and for that, one needs to call ares_cancel?
I thought that ares__destroy_servers_state would be enough.
Also I tried to counter-reinit everything that is initialized in
init_by_resolv_conf
including
Hi Nayana, it's awesome that you want to make this happen.
The problem is actually more complex than this:
* [in some cases] c-ares is the only "good" resolved for libcurl, and
* [when I last checked] c-ares reads /etc/resolv.conf only once
Thus, for a device that moves from network to network
Hi,
so I used just stat as the conf file is small, no need for 64bit version.
However I was not sure if I should ifdef the stat structure usages as well?
So the pull request is there, the only systems that use /etc/resolv.conf
are Linux and OSX, which both passed via CI tests.
I guess there
On Thu, 8 Aug 2019, Nayanā Topolsky wrote:
I used stat64 function to check mtime and ctime and also size and ino values
in very similar way as it is done in libc.
stat(), or variations of it, should be fairly portable over many systems. (In
the curl project we do stat on basically *all*
Hi all,
I found strange corner case bug and I have fix for it for Linux.
I would like to ask whether it makes sense to try to merge it or it has
to have fix for all the platforms.
The bug is that when one calls ares_init when /etc/resolv.conf is empty
(I have it generated only after network
