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: Florian Weimer <fw at deneb dot enyo dot de>
- To: "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 21:30:22 +0100
- 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>
* 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.
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.