This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: On glibc's resolver
On Wed, Dec 26, 2012 at 07:28:31AM +0200, Dimitrios Apostolou wrote:
> >>Apparently this is a known issues, and a web search reveals discussions from
> >>as early as 2003. I'd appreciate your opinions, I was thinking of writing a
> >>patch but I can't figure out where it should go, alpine or glibc, code or
> >>documentation! Here are the replies I gathered from a web search:
> >
> >Could you please provide references to the prior discussions so we can
> >review them also?
>
> Sure, here are some pointers:
>
> Ulrich Drepper proposing the res_init() solution:
> http://sourceware.org/bugzilla/show_bug.cgi?id=3675
>
> Pushing the Debian stat() patch to eglibc:
> http://www.eglibc.org/archives/patches/msg00778.html
>
> Firefox bug from 2003:
> https://bugzilla.mozilla.org/show_bug.cgi?id=214538
>
> Plus various stackoverflow answers proposing a dedicated resolver
> library like c-ares or libunbound.
>
> >
> >>3) Patch glibc to stat() /etc/resolv.conf, checking for changes. Debian,
> >>Ubuntu are patched.
> >
> >This sounds like the worst possible solution, imposing a penalty on
> >all applications for a change that is well defined in a higher level.
>
> The penalty should be negligible if stat() happens after the first
> timeout, right?
Even in calling it directly this penalty is negligible.
Stat call takes few microseconds. As getaddrinfo is typically followed by socket
call you get milisecond latencies and stat penalty is unmeasurable.