Prima di Python 3.7, gli sviluppatori si affidavano esclusivamente a threading.local() per memorizzare dati specifici delle richieste come sessioni utente o connessioni al database. Tuttavia, la proliferazione di asyncio ha rivelato un difetto fondamentale: la memorizzazione locale del thread è condivisa da tutte le coroutine che girano sullo stesso thread dell'event loop. Quando un'attività asincrona cede il controllo, un'altra può accedere o modificare involontariamente lo stato isolato della prima attività, portando a vulnerabilità di sicurezza e corruzione dei dati. PEP 567 ha introdotto contextvars per fornire isolamento del contesto di esecuzione logica indipendente dai thread OS, modellando il concetto sulla base di meccanismi simili in C# ed Erlang.
In Python sincrono, ogni richiesta HTTP tipicamente gira nel proprio thread, rendendo threading.local() sufficiente per memorizzare il contesto della richiesta. Nelle architetture asincrone, migliaia di richieste concorrenti possono multiplexarsi su un singolo thread gestito da un event loop. Se due attività asincrone si sovrappongono—una in pausa su un await mentre l'altra riprende—condividono lo stesso dizionario locale del thread. Senza un meccanismo per acquisire e ripristinare il contesto al cambio di attività, lo stato globale fuoriesce tra operazioni logicamente separate. Questo crea condizioni di gara in cui il token di autenticazione dell'Attività A diventa visibile all'Attività B, o i confini delle transazioni del database si confondono tra richieste non correlate.
Python implementa ContextVar come una chiave in una mappa immutabile memorizzata nello stato del thread. Ogni attività asincrona mantiene un riferimento al proprio oggetto Context, una struttura dati persistente in cui le modifiche creano nuove versioni anziché mutare uno stato condiviso. Quando asyncio sospende un'attività su un await, cattura il contesto corrente; quando riprende, ripristina quel contesto, assicurando che ContextVar.get() restituisca il valore legato a quell'attività specifica anche se i thread OS possono essere cambiati. Questa semantica di copia su scrittura garantisce isolamento senza sovraccarichi di blocco.
import contextvars import asyncio request_id = contextvars.ContextVar('request_id', default='unknown') async def process_task(task_name): # Imposta il valore per questo specifico contesto di attività token = request_id.set(task_name) try: await asyncio.sleep(0.01) # Cede il controllo, possono essere eseguite altre attività current = request_id.get() print(f"Attività {task_name} legge: {current}") finally: request_id.reset(token) # Ripristina il contesto precedente async def main(): # Esegui due attività concorrenti sullo stesso thread await asyncio.gather(process_task('Alpha'), process_task('Beta')) asyncio.run(main())
Un team che costruiva un gateway API ad alto throughput ha migrato da un'applicazione Flask basata su thread a un servizio FastAPI asincrono. Hanno scoperto che il loro middleware di autenticazione, che memorizzava l'utente corrente in threading.local(), stava assegnando in modo casuale l'identità dell'Utente A alle richieste dell'Utente B sotto carico. La debug iniziale suggeriva condizioni di gara, ma i log mostravano che le assegnazioni avvenivano anche in distribuzioni con un solo worker. La causa principale era il multitasking cooperativo di asyncio, in cui un gestore di richieste cede durante una chiamata al database, consentendo a un altro gestore di eseguirsi sullo stesso thread e ereditare la memorizzazione locale del thread.
Il team ha inizialmente tentato di utilizzare un dizionario globale indicizzato da threading.get_ident(), assumendo che questo avrebbe isolato le richieste. Questo approccio offriva una migrazione semplice dal vecchio codice senza introdurre dipendenze esterne. Tuttavia, sotto uvicorn con asyncio, lo stesso thread gestisce più richieste in sequenza, il che significa che il dizionario conservava dati obsoleti da richieste precedenti e causava bug di escalation dei privilegi in cui sessioni autenticate persistevano in modo errato tra richieste non correlate.
Hanno refattorizzato ogni firma di funzione per accettare un parametro di dizionario context, trasmettendolo attraverso l'intero stack di chiamata dal middleware al layer del database. Questo flusso di dati esplicito ha eliminato stati nascosti e ha funzionato attraverso i confini sia sincroni che asincroni. Sfortunatamente, ciò richiedeva un refactoring massiccio che toccava migliaia di funzioni e rompeva le integrazioni delle librerie di terze parti che si aspettavano oggetti di configurazione globali, mentre la verbosità risultante del codice aumentava significativamente il carico di manutenzione e il rischio di errore dello sviluppatore.
Il team ha adottato contextvars.ContextVar per memorizzare l'oggetto utente autenticato, consentendo al middleware di impostare la variabile al momento dell'ingresso nella richiesta mentre le funzioni a valle vi accedevano tramite .get() senza inquinare le firme delle funzioni. Questo approccio non richiedeva una revisione architettonica e forniva isolamento automatico tra attività concorrenti, sebbene richiedesse una gestione attenta dei token reset() per prevenire perdite di memoria in processi a lungo termine. Inoltre, il debug è diventato più impegnativo poiché lo stato è implicito nel contesto di esecuzione piuttosto che visibile negli stack trace.
Hanno infine scelto contextvars perché la prototipazione ha dimostrato che richiedeva modifiche solo al layer middleware, evitando il massiccio refactoring associato al passaggio esplicito del contesto. Avvolgendo i gestori delle richieste in blocchi try/finally per garantire che i token venissero ripristinati, hanno prevenuto perdite di memoria mantenendo firme di funzione pulite. Ora il gateway elabora 50.000 connessioni concorrenti per worker senza fuoriuscite di dati tra richieste, e il team ha ridotto il numero di thread OS da 100 per istanza a 4, riducendo l'uso della memoria dell'80% e migliorando il throughput complessivo del 300%.
Perché threading.local() fallisce nel codice asincrono ma funziona nel codice basato su thread?
In Python multithreading, il sistema operativo pianifica in modo preemptive i thread, e ciascuno mantiene il proprio stack C e la struttura PyThreadState. threading.local() mappa le variabili a questa identità di thread a livello OS, assicurando isolamento. In asyncio, l'event loop pianifica cooperativamente le attività su un singolo thread utilizzando una coda; quando un'attività cede, il loop esegue immediatamente un'altra attività sullo stesso thread senza cambiare PyThreadState. Di conseguenza, threading.local() vede la stessa chiave per entrambe le attività, causando la fuoriuscita di stato. Contextvars risolve questo problema mantenendo uno stack di mapping dei contesti all'interno del PyThreadState che l'event loop scambia durante i cambi di attività, creando isolamento logico indipendente dai thread OS.
Cosa succede se dimentichi di ripristinare un token ContextVar?
ContextVar.set() restituisce un oggetto Token che rappresenta lo stato precedente, che deve essere passato a reset() per ripristinare il valore precedente. Se si trascura questo—forse omettendo un blocco try/finally—la variabile mantiene il proprio valore al di fuori dell'ambito previsto. Nei server asincroni a lungo raggio, ciò crea una perdita di memoria in cui i vecchi contesti di richiesta si accumulano nella catena di contesto, e le attività successive su quel thread possono ereditare valori obsoleti se il contesto non viene ripristinato correttamente. A differenza delle variabili di stack tradizionali che scompaiono quando le funzioni restituiscono, le variabili di contesto persistono nel contesto di esecuzione fino a quando non vengono esplicitamente ripristinate o fino a quando non termina l'attività, rendendo la pulizia obbligatoria.
Come si propagano le variabili di contesto ai task e thread figlio?
Quando si utilizza asyncio.create_task(), l'attività figlio riceve automaticamente una copia del contesto corrente del genitore, assicurando che le variabili di contesto fluiscano naturalmente lungo il grafo di chiamata asincrona. Tuttavia, quando si utilizza concurrent.futures.ThreadPoolExecutor o loop.run_in_executor(), il callable viene eseguito in un thread OS diverso che inizia con un contesto vuoto per impostazione predefinita. I candidati spesso presumono che il contesto si propaghi attraverso i confini dei thread come fa la memorizzazione locale del thread, ma contextvars sono specifiche per il contesto asincrono logico. Per propagare valori ai thread, è necessario acquisire esplicitamente il contesto utilizzando contextvars.copy_context() e eseguire la funzione al suo interno tramite context.run(), oppure passare manualmente le variabili come argomenti.