Le problème du threading DNS que personne n'évoque

Vous vous êtes déjà demandé ce qui se passe en coulisses quand curl gère des dizaines de lookups DNS en parallèle ? Accrochez-vous.

Avant, le résolveur threadé de curl fonctionnait ainsi : pour chaque connexion parallèle, une nouvelle thread naissait, avec un socketpair (ou eventfd sous Linux) pour synchroniser les résultats. Inefficace ? Totalement.

Pour quelques transferts, ça passe inaperçu. Mais en entreprise, avec des milliers de connexions simultanées ? Ça dégénère vite. Chaque thread bouffe mémoire, CPU et ressources OS. Chaque socketpair alourdit les file descriptors. À l'échelle, c'est un cauchemar linéaire.

Pire : un lookup DNS bloqué figeait tout le nettoyage. Supprimer un easy handle pendant que sa thread traînait ? Deadlock garanti.

L'astuce d'avant (et ses limites)

L'équipe curl proposait CURLOPT_QUICK_EXIT. Ça détachait les threads au lieu de les attendre – idéal pour une app qui s'arrête. Mais si elle tourne longtemps ? Les threads détachés s'accumulaient en fantômes, grignotant la mémoire jusqu'à la fin du process.

Un pansement bancal.

Le pooling de threads : la révolution de curl 8.20.0

La dernière version enterre l'ancien système. Elle introduit un pool de threads au niveau multi handle.

Voici le nouveau design malin :

Un seul pool pour tout

Fini une thread par easy handle. Un pool géré par multi handle, qui :

• Lance des threads à la demande (pas de gaspillage)
• Tue les inactifs après un délai
• Met les requêtes DNS en file d'attente
• Diffuse les résultats via un canal partagé
• Rénvoie les réponses aux bons easy handles

Clé : un seul socketpair par multi handle, quel que soit le nombre de connexions. Adieu l'explosion des file descriptors pour des centaines ou milliers de transfers.

Vous prenez les rênes

CURLMOPT_RESOLVE_THREADS_MAX limite le nombre max de threads résolveuses. Par défaut : 20, ajustable avec vos retours.

Plus de consommation folle. Besoin de 5 threads pour économiser du CPU ? C'est fait. 50 pour du max débit ? Pareil.

Nouveau CURLMOPT_QUICK_EXIT au niveau multi pour vider le pool vite à la fin du process. Sans threads individuelles, supprimer un easy handle est safe. Résolutions tardives ? Jetées à la poubelle. Net et prévisible.

Le gain perf (en général)

Outre les économies, le pooling booste subtilement : les lookups DNS tournent dans des threads déjà chauds. Pas de démarrage, pas d'allocs mémoire redondantes, moins de syscalls.

Vitesse folle ? Ça dépend de votre setup. Mais globalement mieux : moins d'opérations, moins de switches de contexte, latence stable.

Attention : du neuf, des bugs possibles

Gros refactor. Plus de code, plus de pièces mobiles, plus de pièges.

Les devs curl sont confiants, mais testez en prod. Les releases majeures cachent toujours des surprises.

Ce que ça change pour vous

Apps à haut débit (scrapers web, pipelines data, downloaders distribués) : curl 8.20.0+ réduit mémoire, CPU et prévisibilité. Upgrade majeur.

Systèmes embarqués ou IoT : chaque octet et cycle compte. Moins de threads et FD, c'est du concret.

Usage modeste : gains invisibles. DNS plus rapides, moins de syscalls. Votre infra dit merci.

Le contexte large

L'initiative DNS 2026 de curl (dont ce pooling est un pilier) montre un engineering mature : problème ID, solution propre, compat rétro + options neuves. Rien de cassé, tout amélioré.

C'est ça, l'open source qui prend perf et ressources au sérieux.

Vous avez testé curl 8.20.0 ? Migré votre infra ? Laissez un com' avec vos retours – l'équipe curl kiffe le feedback réel pour affiner.