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*. _______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python