Buy commercial curl support. We
help you work out your issues, debug your libcurl applications, use the API,
port to new platforms, add new features and more. With a team lead by the
curl founder Daniel himself.
Re: libcurl 8.16.0 spawning large number of getaddrinfo threads?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Demi Marie Obenour <demiobenour_at_gmail.com>
Date: Mon, 20 Oct 2025 13:29:27 -0400
On 10/19/25 06:01, Daniel Stenberg wrote:
> On Sat, 18 Oct 2025, Demi Marie Obenour via curl-library wrote:
>
>> Should distros build with c-ares by default? I'm wondering if getaddrinfo()
>> is just too poor an interface.
>
> Yes, getaddrinfo is a terrible interface and getaddrinfo_a is not helping.
>
> Unfortunately, doing a 100% functional drop-in replacement for getaddrinfo has
> turned out to be a really difficult task. Several distros have through times
> tried to ship curl built with c-ares for this reason, but so far everyone has
> eventually had to back down from that decision because of some special edge
> case where c-ares did not behave like getaddrinfo.
>
> With luck, one future day c-ares has gotten all of those problems ironed out
> and we can switch to a proper asynchronous name resolver more universally...
Personally I think all distros should ship a validating resolver that
listens on loopback. c-ares could then talk to it.
In the future it might make sense for curl to use systemd-resolved's
D-Bus API or the ncsd IPC API.
Received on 2025-10-20
Date: Mon, 20 Oct 2025 13:29:27 -0400
On 10/19/25 06:01, Daniel Stenberg wrote:
> On Sat, 18 Oct 2025, Demi Marie Obenour via curl-library wrote:
>
>> Should distros build with c-ares by default? I'm wondering if getaddrinfo()
>> is just too poor an interface.
>
> Yes, getaddrinfo is a terrible interface and getaddrinfo_a is not helping.
>
> Unfortunately, doing a 100% functional drop-in replacement for getaddrinfo has
> turned out to be a really difficult task. Several distros have through times
> tried to ship curl built with c-ares for this reason, but so far everyone has
> eventually had to back down from that decision because of some special edge
> case where c-ares did not behave like getaddrinfo.
>
> With luck, one future day c-ares has gotten all of those problems ironed out
> and we can switch to a proper asynchronous name resolver more universally...
Personally I think all distros should ship a validating resolver that
listens on loopback. c-ares could then talk to it.
In the future it might make sense for curl to use systemd-resolved's
D-Bus API or the ncsd IPC API.
-- Sincerely, Demi Marie Obenour (she/her/hers)
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
- application/pgp-keys attachment: OpenPGP public key
- application/pgp-signature attachment: OpenPGP digital signature