> > > E capisci anche che praticamente *tutte* le operazioni su questi oggetti > devono essere protette da un lock. Perche'? Beh... perche' se siamo in > memoria condivisa vuole dire che piu' processi possono accedervi (o > meglio... se li ho messi in memoria condivisa e' perche' voglio accederci > da piu' processi). > > Ecco... come ne usciamo? Abbiamo due soluzioni: > 1. mettiamo un lock poco granulare sull'area di memoria > 2. mettiamo lock granulari sugli oggetti >
Non mi sono spiegato: non si metterebbe NESSUN lock per l'accesso a quest'area. Sarebbero affari del programma quando come e perché lavorarci sopra. Per il resto, e' un oggetto che riserva molte sorprese, e non del tipo > divertente. > > Se hai un problema I/O bound guardati cose come gevent, tornado, il > vecchio twisted o il nuovo asyncio. > concordo per asyncio, se del caso. > Se hai un problema CPU bound... boh, fai offload a chi puoi. Numpy in > certi casi. Se no a volte con un po' di attenzione si possono fare cose > belline con multiprocessing. Poi per dire l'ultima volta che lo ho messo in > produzione mi sono scritto a mano tutte le primitive di comunicazione fra > processi, perche' le implementazioni di default di multiprocessing non > facevano per me (semantica, + tirano su thread, + sono lente... etc etc > etc). Questo non vuole dire che per te non andranno bene: probabilmente se > sono ancora li, vuole dire che vanno bene per la maggior parte delle > persone. > concordo anche qui. In effetti stavo proprio pensando a casi specifici. Proverò. Alex
_______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
