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 moved to
a new network, it's unreasonable to expect the old request to succeed.
on the other, if only a small part of `resolv.conf` was changed, it's
odd to break user's requests.
I am somewhat concerned by the idea of reloading only a part of
resolv.conf; I feel that will only work in basic. Maybe that's worth
is to start. Ideally maintainer would weigh in on this.
On Mon, 26 Aug 2019 at 17:20, Nayanā Topolsky <nayana.topolsky_at_zoho.com> wrote:
>
> 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 domain and nameserver.
> In my patch I am clearing all channel values and call init_by_resolv_conf once again so every information in
> /etc/resolv.conf shall end up in channel struct values.
>
> Did I missed something?
> This is for instance clearing of domains:
> https://github.com/nayana-sue/c-ares/commit/696a1d59be106520a0471348caa469b03aa477ae#diff-6c5528d5eccbe836842006e4f0cb89baR1900
>
> Of course your patch is much more robust because you also load the parameters values,
> which I do not do (it can be added to my patch, but then I might do the whole ares_init as you do).
> What is missing in your patch that needs some more work?
>
> Thanks for your feedback and insights,
>
> Nayanā
>
> Dňa 26. 8. 2019 o 3:22 Dima Tisnek napísal(a):
>
> 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 (e.g. wifi), has
> a long-running process, needs domain name resolution timeouts (e.g.
> wifi) and some other requirements (multithreaded IIRC, because libc
> resolver uses a signal for timeout), this really is a problem.
>
> It may seem that this circumstances are peculiar, but, actually many
> IoT devices fall into this category.
>
> Back in the day, I've tried to make a patch, but didn't have
> time/stamina and couldn't put enough effort for it to be accepted.
>
> https://gist.github.com/dimaqq/397682b68cdc0992a5d314c53e8ecf86 has the code.
>
> The task is somewhat more complex than you stated, because resolv.conf
> may contain several bits of configuration, and sometimes partial
> update could break things (IIRC to resolve a LAN host, both `domain`
> and `nameserver` are needed).
>
> Cheers,
> d.
>
> On Thu, 15 Aug 2019 at 21:36, Nayanā Topolsky <nayana.topolsky_at_zoho.com> wrote:
>
> 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 are no win32 automated tests?
>
> Dňa 9. 8. 2019 o 9:02 Daniel Stenberg napísal(a):
>
> 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* platforms with just this little setup magic: https://github.com/curl/curl/blob/master/lib/curl_setup.h#L361-L396)
>
> The particular file name(s) you check which that call could also be system specific but should be possible to be made to work on a fair amount of systems.
>
> I can send a patch (or pull request) with hope that somebody else will continue the work on it. Or maybe it would be mergable even in this way.
>
>
> We will prefer a pull-request so that we get it somewhat verified before we consider merging and handling updates and reviews are also stream-lined that way.
>
> We can't guarantee that "somebody else" will magically continue working on it if you just drop it there though, I suppose it depends on how much work that remains...
>
> Thanks!
>
Received on 2019-08-28