[Python] saluti e prima domanda sulle list comprhension

Enrico Franchi enrico.franchi a gmail.com
Mar 29 Gen 2008 11:31:12 CET


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*.




More information about the Python mailing list