Il Problema del Threading DNS in Curl che Nessuno Menziona

Hai mai pensato a cosa succede quando curl gestisce decine di risoluzioni DNS in parallelo? Preparati a una sorpresa, o almeno a un sopracciglio alzato.

Prima di curl 8.20.0, il resolver threaded funzionava così: per ogni connessione parallela, nasceva un thread dedicato con un socketpair (o eventfd su Linux) per sincronizzare i risultati. Inefficiente? Decisamente sì.

Con poche trasferte, non si nota nulla. Ma in applicazioni enterprise con migliaia di connessioni simultanee? Ecco il caos. Ogni thread mangia memoria, CPU e risorse del sistema operativo. Ogni socketpair aggiunge overhead sui file descriptor. Moltiplica per migliaia di easy handle, e ottieni un incubo di risorse che scala linearmente.

Peggio ancora: una risoluzione DNS bloccata poteva fermare tutto il processo di cleanup. Rimuovere un easy handle con il thread incastrato? Deadlock assicurato.

La Soluzione Temporanea (e i Suoi Limiti)

Il team di curl offriva CURLOPT_QUICK_EXIT: imposta quello, e i thread si staccano invece di sincronizzarsi. Ideale per app che terminano subito. Ma se l'applicazione doveva continuare? I thread staccati si accumulavano in memoria, un esercito fantasma che prosciugava risorse fino alla fine del processo.

Un cerotto, non una cura vera.

Thread Pooling: La Rivoluzione di Curl 8.20.0

L'ultima release butta via il vecchio approccio e introduce il thread pooling a livello di multi handle.

Ecco la nuova struttura, pulita e scalabile:

Un Solo Pool per Multi Handle

Niente più un thread per easy handle. Ora c'è un pool gestito per multi handle che:

• Avvia thread solo quando servono (niente sprechi)
• Chiude i thread inattivi dopo un po'
• Mette in coda le richieste DNS
• Notifica i risultati via meccanismo condiviso
• Assegna le risoluzioni completate all'easy handle giusto

Il clou? Un solo socketpair per multi handle, indipendentemente dal numero di connessioni. Per app con centinaia o migliaia di trasferte, è un taglio drastico sui file descriptor.

Controllo Totale nelle Tue Mani

Con CURLMOPT_RESOLVE_THREADS_MAX decidi il numero massimo di thread resolver. Default a 20, ma il team curl lo affinerà coi feedback reali.

Non sei più schiavo di consumi incontrollati. Vuoi solo 5 thread per risparmiare CPU? Fatto. Ne servono 50 per massimizzare il throughput? Regolalo pure.

C'è pure un CURLMOPT_QUICK_EXIT a livello multi, per spegnere il pool al termine del processo senza attese. E ora, rimuovere easy handle è sicuro: niente thread bloccati. Risoluzioni DNS in ritardo dopo la rimozione? Buttate via. Tutto prevedibile.

I Vantaggi in Prestazioni (Quasi Sempre)

Oltre al risparmio di risorse, il pooling dà un boost reale: molte risoluzioni DNS usano thread già attivi. Niente overhead di avvio, allocazioni ripetute o system call inutili.

Vedrai un'accelerazione enorme? Dipende dalla tua app e dal sistema. Ma è sempre meglio del passato: meno switch di contesto, latenza più stabile.

Attenzione: Codice Nuovo, Possibili Inconvenienti

Cambiare architettura così non è roba da poco. Più codice, più parti mobili, più angoli bui per bug.

Gli sviluppatori di curl sono fiduciosi, ma come ogni refactor grosso, i problemi emergeranno. Testa la nuova versione nel tuo ambiente, punto.

Cosa Cambia per Te

App ad alto throughput con migliaia di connessioni parallele (scraper web, tool di data pipeline, downloader distribuiti)? Curl 8.20.0+ è un upgrade serio: meno memoria, CPU più efficiente, risorse prevedibili.

Sistemi embedded o IoT dove ogni byte conta? Il taglio su thread e file descriptor fa la differenza vera.

Uso modesto di curl? I benefici ci sono, invisibili: risoluzioni DNS più rapide, meno system call. La tua infrastruttura ringrazia.

Il Contesto Più Ampio

L'iniziativa DNS 2026 di curl (di cui il pooling è parte chiave) mostra ingegneria matura: problema individuato, soluzione elegante, compatibilità backward e opzioni nuove. Niente rotture, solo miglioramenti.

Ecco cosa succede quando gli maintainer open-source prendono sul serio performance e risorse.

Hai già provato curl 8.20.0? Stai aggiornando la tua infrastruttura? Lascia un commento con le tue esperienze: il team curl usa il feedback reale per queste scelte architetturali.