curl 8.20.0: So behebt die DNS-Threading-Lücke – Ein Blick ins Resource Pooling
Das DNS-Threading-Problem, das keiner anspricht
Stell dir vor, curl jongliert mit Dutzenden parallelen DNS-Anfragen. Was da im Hintergrund abläuft, ist ein echter Schocker – oder mindestens ein Grund zum Augenbrauenheben.
Bis vor Kurzem hat curls Thread-Resolver so gearbeitet: Pro paralleler Verbindung ein neuer Thread plus Socketpair (oder eventfd unter Linux) für die Koordination. Effizient? Weit gefehlt.
Bei ein paar Transfers merkt man nichts. Aber in Enterprise-Apps mit Tausenden gleichzeitiger Verbindungen? Da explodiert der Ressourcenverbrauch. Jeder Thread frisst Speicher, CPU und Systemressourcen. Jedes Socketpair belastet die File Descriptors. Bei Hunderten Easy Handles skaliert das linear – pure Katastrophe.
Schlimmer noch: Hängt eine DNS-Auflösung, blockiert sie die gesamte Aufräumroutine. Easy Handle entfernen, während der Resolver-Thread feststeckt? Hallo Deadlock.
Der alte Hack (und seine Schwächen)
Curl bot CURLOPT_QUICK_EXIT als Pflaster. Threads werden detached statt gejoined – super für Apps, die eh auslaufen. Aber bei laufenden Systemen? Die losgelösten Threads stapeln sich im Speicher, saugen Ressourcen – bis zum Prozessende.
Typischer Workaround, der mehr schadet als nützt.
Thread-Pooling revolutioniert alles: curl 8.20.0
Die neue curl-Version wirft das alte System über Bord und setzt auf Thread-Pooling auf Multi-Handle-Ebene.
So läuft die smarte neue Struktur:
Ein Pool pro Multi Handle für alle Verbindungen
Kein Thread pro Easy Handle mehr. Stattdessen ein zentraler Pool, der:
- Threads bei Bedarf startet (kein unnötiges Vorab-Alloc)
- Faule Threads nach Inaktivität killt
- DNS-Anfragen queued
- Ergebnisse via shared Notification verteilt
- Fertige Auflösungen ans richtige Easy Handle schickt
Der Clou: Nur ein Socketpair pro Multi Handle, egal ob 10 oder 10.000 Transfers. File-Descriptor-Overhead geschrumpft – ideal für Massenverbindungen.
Du hast die Kontrolle
Mit CURLMOPT_RESOLVE_THREADS_MAX bestimmst du die Obergrenze für Resolver-Threads. Default: 20, anpassbar per Feedback.
Kein wildes Wachstum mehr. Willst du auf 5 Threads beschränken, um CPU für deine Logik zu sparen? Einfach setzen. Brauchst 50 für Top-Throughput? Kein Problem.
Neuer CURLMOPT_QUICK_EXIT auf Multi-Ebene regelt den Pool-Shutdown. Perfekt für Prozessende, ohne Warten. Easy Handles ohne eigene Threads entfernen? Kein Risiko mehr. Späte DNS-Ergebnisse nach Handle-Removal? Weg damit. Sauber und vorhersehbar.
Der Performance-Boost (meistens)
Neben Ressourcen-Einsparung kommt ein echter Zuwachs: Viele Auflösungen laufen in laufenden Threads. Kein Start-Overhead, weniger Allocs, sparsame Systemcalls.
Riesiger Speed-Jump? Hängt von deiner App ab. Aber immer besser: Weniger Switches, stabilere Latenz.
Warnung: Neuer Code, neue Fallen
Große Umbaumaßnahme heißt mehr Code, mehr Komplexität, mehr Risiken für Edge-Cases.
Die Curl-Entwickler sind zuversichtlich, aber bei Refactors tauchen Bugs auf. Testet die neue Version gründlich in eurer Umgebung.
Was das für dich bedeutet
High-Throughput-Apps mit Tausenden Verbindungen (Web-Scraper, Data-Pipelines, Bulk-Downloader)? Curl 8.20.0+ spart Speicher, CPU und macht Verhalten vorhersehbar.
Embedded oder IoT-Systeme, wo jeder Byte zählt? Weniger Threads und Descriptors sind Gold wert.
Normale Nutzung? Unsichtbare Verbesserungen: Schnellere DNS, weniger Calls. Deine Infra sagt danke.
Der große Kontext
Curls DNS-2026-Initiative (wovon Thread-Pooling ein Kernstück ist) zeigt Reife: Problem erkannt, saubere Lösung, volle Backward-Compat plus neue Optionen. Nichts gebrochen, alles besser.
So pflegen Open-Source-Teams Performance ernst.
Curl 8.20.0 schon getestet? Infra upgedatet? Teilt eure Erfahrungen in den Comments – das Curl-Team baut realen Feedback direkt ein.