getaddrinfo() blocks indefinitely when DNS query times out

Direct Answer

The safest portable way to bound getaddrinfo() is to run it in a separate process and enforce the deadline in the parent. Do not rely on thread cancellation.

Confirmed Facts vs. Likely Explanation

Confirmed: getaddrinfo() exposes no timeout parameter, and blocking duration is governed by resolver configuration and libc defaults—/etc/resolv.conf options on glibc, hard-coded defaults in musl, and registry or service settings on Windows. Likely: cancelling a thread blocked in getaddrinfo() leaves glibc, musl, or Windows resolver internals inconsistent, though the exact failure mode varies by platform and version.

Separating Transient, Permanent, and Timeout Failures

Treat three outcomes as distinct:

• EAI_AGAIN: temporary resolver failure (server unreachable, transient network issue). Retry with backoff is appropriate.
• EAI_NONAME: permanent name resolution failure. Retrying the same query is usually futile.
• Wrapper timeout: your isolation layer exceeded its deadline. Do not map this to EAI_AGAIN; it is a third class that may warrant a different retry policy or circuit breaker.

Portable Isolation Pattern

On POSIX systems (glibc, musl), fork a child that calls getaddrinfo() and writes the result back over a pipe. The parent uses waitpid() or a timed read; if the deadline passes, send SIGKILL to the child. This avoids leaving resolver mutexes or file descriptors in an inconsistent state.

On Windows there is no fork(). Use a helper process via CreateProcess() with an inherited pipe, or delegate to an asynchronous DNS library such as c-ares. A worker thread that is simply abandoned—not cancelled—is less dangerous than pthread_cancel(), but it still consumes a thread until the resolver unblocks.

What to Avoid

Asynchronous thread cancellation (pthread_cancel(), TerminateThread()) is not safe across these platforms. glibc, musl, and the Windows resolver may hold internal locks or sockets that are never released, causing deadlocks or descriptor leaks for subsequent lookups in the same process.

Verification

Build a small test that forks a child resolving a name routed to a non-responsive server. Confirm the parent returns within your deadline and that the child is reaped. Repeat on each target libc and OS version, because resolver defaults and AI_ADDRCONFIG behavior vary.

Open Question

Can your application spawn a helper process, or must it remain a single process? If a helper process is acceptable, the fork-and-wait pattern above is the most portable. If not, an async DNS library is the safer in-process alternative.