Hvordan curl 8.20.0 fik DNS-trådene: Dypdykk i resource pooling

DNS-tråding-problemet ingen snakker om

Har du lurt på hva som skjer når curl håndterer dusinvis av DNS-oppslag samtidig? Da er det på tide å ta en titt bak kulissene.

Før nylig fungerte curl sin trådbaserte resolver sånn: For hver parallell forbindelse startet biblioteket en egen tråd og åpnet en socketpair – eller eventfd på Linux – for å samle inn resultater. Høres sløsing ut? Det var det også.

Med få overføringer merker du ingenting. Men i store applikasjoner med tusenvis av samtidige koblinger? Da blir det kaos. Hver tråd spiser minne, CPU og systemressurser. Socketpair-ene legger på seg med filbeskrivere. Skaler det opp til tusenvis av easy handles, og du har en lineær ressurskrise.

Verre: Et hengende DNS-oppslag kunne blokkere hele opprydningen. Fjern en easy handle mens resolver-tråden henger? Hei, app-deadlock.

Den gamle fiksingen (og hvorfor den sugde)

Curl-folket hadde en midlertidig løsning: CURLOPT_QUICK_EXIT. Sett den, og trådene detaches i stedet for å join-es – greit for apper som stenger uansett. Men hvis appen din skulle kjøre videre? Da samlet detached tråder seg som spøkelser i minnet og sugde ressurser til prosessen døde.

Ren og sheer kludge.

Thread pooling entrer scenen: curl 8.20.0 endrer alt

Nyeste curl-kaster det gamle designet og ruller ut thread pooling på multi handle-nivå.

Slik ser den smarte nye modellen ut:

Én trådpool, ubegrenset koblinger

I stedet for en tråd per easy handle får du én styrt pool per multi handle. Den:

• Starter tråder etter behov, uten unødvendig forhåndsallokering
• Dreper inaktive tråder når det er stille
• Setter innkommende DNS-forespørsler i kø
• Sender resultater via én delt kanal
• Fordeler ferdige oppslag til rett easy handle

Nøkkelen? Kun én socketpair per multi handle, uansett antall parallellkoblinger. Dramatisk færre filbeskrivere for apper med hundrevis eller tusenvis av overføringer.

Du styrer selv

Ny option CURLMOPT_RESOLVE_THREADS_MAX lar deg sette tak for antall resolver-tråder. Standard er 20, men curl-teamet justerer basert på feedback.

Ingen mer ukontrollert ressursbruk. Vil du ha maks 5 tråder for å spare CPU til app-logikken din? Sett det til 5. Trenger du 50 for topp hastighet? Mulig.

Ny multi-nivå CURLMOPT_QUICK_EXIT styrer pool-avvikling. Bruk den ved shutdown uten å vente på opprydning. Easy handles eier ikke lenger egne tråder, så du kan fjerne dem trygt – uten hengende join-operasjoner.

DNS-resultater som kommer sent etter fjerning? De kastes. Rent og forutsigbart.

Ytelsesgevinsten (som regel)

Mindre ressursbruk er én ting. Den nye pooling gir også boost: Mange DNS-oppslag kjører i eksisterende tråder. Ingen oppstartskostnad. Færre allokeringer. Mindre systemkall.

Massiv hastighetsøkning? Avhenger av app og maskin. Men det er alltid bedre – mindre switching, jevnere ventetid.

Realitetsjekk: Ny kode, nye feil

Dette er stor arkitekturendring. Mer kode. Flere deler. Potensial for edge cases.

Curl-utviklerne tror de har det under kontroll, men som med alle refaktoringer: Test grundig i ditt miljø.

Hva det betyr for deg

Hvis du bygger high-throughput-apper med tusenvis av parallellkoblinger – som web scrapere, datapipelines eller downloadere – er curl 8.20.0+ gull. Lavere minnebruk, bedre CPU og stabil ressursadførsel.

For embedded eller IoT der hver byte og syklus teller: Mindre tråd- og FD-overhead gir reell effekt.

Ved moderat skala merker du kanskje ikke noe. Men DNS går raskere med færre kall. Infrastrukturen din smiler.

Det store bildet

Curl sin DNS 2026-satsing – der thread pooling er kjernen – viser moden engineering: Finner problem, lager ren løsning, beholder kompatibilitet og gir nye knapper. Ingenting ødelagt. Alt bedre.

Sånn ser det ut når open source tar ytelse og ressurser på alvor.

Har du testet curl 8.20.0? Oppgradert infrastrukturen? Del erfaringene i kommentarene – curl-teamet bruker ekte feedback til å finpusse.