[Python] saluti e prima domanda sulle list comprhension

[Enrico Franchi]

On Jan 28, 2008, at 8:47 PM, Java wrote:

> Ma scusa, invece se lancio due processi, ognuno dei quali deve  
> scrivere
> sullo stesso file non ci sono race conditions?

In linea abbastanza teorica, si. In pratica il punto è *cosa* devono  
farci di sensato per scrivere tutti e due sullo stesso file.
E' un log? Beh, allora basta lasciare gestire la cosa al sistema  
operativo: siamo solo in append e non importa se una delle due righe è  
prima dell'altra (e il buffering dell'OS Normalmente gestisce la cosa  
-- e se non lo fa, chissene).

Hai più processi che devono scrivere sullo stesso file e non ci puoi  
fare nulla architetturalmente?

Bene: è il momento per usare i lock. Esatto! Oppure, se per vari  
motivi la cosa è sensata/fattibile deleghi la scrittura ad un unico  
processo che prende messaggi dagli altri. Questa è la soluzione dello  
spooler di stampa, in buona sostanza.

Ma in generale è quello che accade per esempio su un database system.  
Ci sono varie soluzioni, ovviamente.

Ma la tua obiezione è del tipo: c'è un caso complicato e noioso che in  
determinate occasioni si manifesta. Per cui chi se ne impippa se lo  
facciamo manifestare sempre. Io invece ti rispondo: facciamolo  
manifestare il meno possibile.

Dopo di che un conto è avere un lock su un'operazione di I/O che  
bloccherebbe comunque, un conto è avere un lock su una variabile in  
ram che di per se potrebbe essere gestita in qualche boh, qualche  
nanosecondo. Direi che sono cose *radicalmente* diverse. A fronte di  
*nessun* vantaggio concreto.

> Devo comunque mettere su dei lock sul file e il processo che trova il
> file lockato (ARGH!) si siede e aspetta giocando con la psp.

E quindi? E' comunque I/O. Se non puoi evitare il problema, almeno  
rendilo raro. Inoltre, come dicevo, l'overhead su un'operazione di  
questo tipo è percentualmente molto più piccolo che averlo su un  
accesso in memoria.


> qualcuno mi ha proposto la gestione asincrona della cosa, ma come ho
> detto "asincrono" mi puzza di "gestione di eventi e segnali" che è di
> certo più tediosa di un piccolo lock...

'Di certo' poi un accidenti. In primo luogo perchè buona parte del  
meccanismo ti viene gestito dal sistema (non è che twisted se lo sono  
inventato per il divertimento di fare passare una poll per 12 strati  
software diversi, eh).

Anche fare le cose a mano, non è poi terribilmente noioso, se hai ben  
progettato il sistema. Ribadisco poi che con Twisted è tutto *gratis*.  
Nota bene che qui non sono mica solo io a dirti di tenerti lontano dai  
thread, ma c'è una certa unanimità a riguardo. Non è che ci siamo  
messi d'accordo. Come dicevo, potrei anche segnalarti fonti letterarie  
a riguardo.

I thread sono spinti e difesi in sostanza dai javisti principalmente  
perchè se no gli crolla il mondo addosso. Hanno pure tentato approcci  
asincroni, ma non so se per incapacità loro, problemi di linguaggio,  
macchina virtuale o cosa, sono solo riusciti a complicare il tutto. Ma  
questo è un problema *loro*.