This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: More on SIGINT, longjmp, and getaddrinfo
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Florian Weimer <fw at deneb dot enyo dot de>, "Carlos O'Donell" <carlos at systemhalted dot org>
- Cc: Hal Murray <hmurray at megapathdsl dot net>, "libc-help at sourceware dot org" <libc-help at sourceware dot org>
- Date: Mon, 22 Feb 2016 15:35:30 -0500
- Subject: Re: More on SIGINT, longjmp, and getaddrinfo
- Authentication-results: sourceware.org; auth=none
- References: <20160222014052 dot CACDF406060 at ip-64-139-1-69 dot sjc dot megapath dot net> <CAE2sS1jG30g52PO7F4HHbZXhQZ6jndkqL=fTDfVojgr+y93HWQ at mail dot gmail dot com> <871t841o9t dot fsf at mid dot deneb dot enyo dot de>
On 02/22/2016 03:30 PM, Florian Weimer wrote:
> * Carlos O'Donell:
>
>>> What is the worst cast time for getaddrinfo or getnameinfo to return? I
>>> assume the really nasty case would involve several retransmissions on each of
>>> several different steps so the worst case could be horribly long. How about
>>> an estimate for a simple dead-server case? Is there a limit on the number of
>>> steps? ...
>>
>> There is a limit.
>
> There is not. Not with DNS, due to bug 19643. There is no
> overarching timeout for TCP, so you get the kernel default timeout for
> the connect call, and potentially no timeout at all if the TCP
> connection is silently severed in just the wrong state.
I stand corrected :-)
That sucks, but bugs are bugs. I think we should fix 19643 in the general
cleanup for resolv/ that we're going to do.
> And that's just DNS. We don't know for certain what other NSS service
> modules do. I have nss_files tests (which I still need contribute)
> that take a few dozen seconds to run.
Right. You could have all sorts of private nss modules we know nothing
about that resolve host names via any protocol you can think about.
Cheers,
Carlos.