***********
Rimando nella speranza che qualcuno legga e desideri e magari stia
cercando di combattere la noia...
***********

Ciao,

[disclaimer: si parla di Django ma il tema mi pare più generale poi si
parla di uwsgi e mi pare che Roberto qui legga...]

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

[1] 
https://stackoverflow.com/questions/3227180/why-is-using-thread-locals-in-django-bad
[2] https://www.pythonanywhere.com/forums/topic/710/
_______________________________________________
Python mailing list
Python@lists.python.it
https://lists.python.it/mailman/listinfo/python

Rispondere a