Ciao Marco,
grazie per la risposta e l'attenzione. > > al lavoro abbiamo avuto una interessante discussione su un modo di > > tenere in Django una informazione sempre disponibile (request / user e > > recentemente un 'dominio'). > > > > Una soluzione a volte considerata "da evitare" ma che ci è sempre > > andata bene è stata fatta seguendo un vecchio snippet di Django [2 - > inizio] > > che immagazzina i dati in threading local(). > > > > Quello che mi ha fatto balzare sulla sedia ieri è che un collega mi ha > > mostrato un post [1] su StackOverflow dove si dice che uwsgi non > > garantisce che quello che si mette in local() non sia condiviso fra > > thread differenti... nonostante la documentazione Python dica: > > > > Thread-local data are data whose values are thread specific > > > > > > In una pagina citata in questo post [2] si espone una situazione molto > > simile alla mia, ma non vedo una risposta soddisfacente sul fatto che > > sia in effetti vero > > > > * che uwsgi forza un uso condiviso della ram fra thread differenti e > > * se esiste un modo per bypassarlo > > > > io ho spesso in uwsgi.ini (ma ho anche occasionalmente di più): > > > > threads: 1 > > processors: 2 > > > > È questo che mi ha salvato fino ad oggi? > > > > > > sandro > > *:-) > > > > > > PS: tecnicamente io scrivo nel _thread_local tramite middleware ad > > ogni request, non esiste possibilità che resti il vecchio nella > > nuova request > > > Ciao Alessandro, > > incuriosito dalla tua domanda e partaggiando il tuo stesso stupore ho > fatto qualche ricerca. > > Prima di tutto vorrei iniziare dicendo che faccio piu' confidenza al > gruppo di unbit piuttosto che al commento di qualcuno in un sito. Mi > sembrava di aver letto nella documentazione di uWSGI che l'obiettivo > principale di uWSGI sia la correttezza, le performance vengono dopo. > Ovviamente non ritrovo la frase in questione ma che cambino la semantica > di threading.local per ragioni di performance mi sembra un suicidio. Se > fai un veloce grep nel codice di Django ti accorgerai che Django stesso > usa local() internamente. > > Per scrupolo ho fatto una piccola ricerca nei sorgenti di uWSGI e non > trovo conferma di una simile castroneria. > > Sono gia' bloccato, non so' piu' come continuare. Sono stati portati > esempi concreti a supporto della tesi? No. > > Allego due file di test e come puoi verificare e threading.local > funziona esattamente come ci si aspetterebbe. Avendo sollecitato Roberto De Ioris anche in privato, mi ha in effetti risposto: Ciao, di solito si usano i thread local per avere dati NON-condivisi tra i thread. Se e' il tuo caso, allora puoi usarli senza problemi a patto che abiliti il GIL in uWSGI con --enable-threads. Va da sè che se non abilito --enable-threads, problema non ne ho, visto che non uso threads... e --threads imploca --enable-threads. > In realta' e' l'altro risultato che mi lascia dei dubbi, quando > threading.local non e' usato. Qui ti ho perso... quale sarebbe "l'altro risultato"? sandro *:-) _______________________________________________ Python mailing list Python@lists.python.it https://lists.python.it/mailman/listinfo/python