Context local e sicurezza dei thread

Come può un unico oggetto globale request rimanere corretto quando molti visitatori accedono contemporaneamente all’app? La risposta sono i locali del contesto.

Oggetti come request e g sembrano normali globali importati una volta sola. In realtà sono proxy speciali, non variabili condivise ordinarie.

Un proxy inoltra ogni accesso all’oggetto reale del contesto corrente. Ogni richiesta vede i propri dati attraverso lo stesso import.

Flask chiama questi elementi context locals. Si comportano come locali del thread, ma si basano sul contesto attivo, quindi le richieste concorrenti non entrano mai in conflitto.

Due thread che gestiscono due richieste ricevono ciascuno il proprio contesto associato. Pertanto, request in un thread non mostra mai i dati dell’altro thread.

Le versioni moderne di Flask usano contextvars, quindi l’isolamento è garantito anche per greenlet e attività asincrone, non solo per i thread del sistema operativo.

Per questo un singolo import all’inizio del file è sicuro. Il proxy si risolve in un oggetto reale diverso per ogni richiesta.

Se avvia un thread semplice da una vista, questo non dispone di alcun contesto. L’accesso a request fallisce, a meno che non attivi personalmente un contesto.

Passi a un worker in background il value effettivo di cui ha bisogno, ad esempio un ID utente, invece del proxy della richiesta, che a quel punto non sarà più disponibile.

Le serve l’oggetto sottostante a un proxy? Utilizzi _get_current_object, ma vi ricorra raramente e solo quando è davvero necessario.

I locali del contesto spiegano perché Flask sembra semplice: importa request una sola volta e vi fa affidamento, mentre il framework mantiene discretamente isolate tutte le richieste.

I globali di Flask sono in realtà context-local proxies. Si risolvono per ogni richiesta, mantenendo isolati thread e attività asincrone, così un unico import rimane sicuro ovunque. 🎉