On Jan 28, 2008, at 11:32 AM, [EMAIL PROTECTED] wrote: > Bho, fore ora andiamo anche OT, ma mi sento di dissentire quest'ultima > affermazione.
Dissenti, ma sbagli :) > Se non altro dopo tutti i vari "filosofi a cena" e "barbieri" > fatti a laboratorio concorrente. Quindi? In primo luogo, cerchiamo di capire quale è il senso. Sono problemi *teorici*, spesso usati come metro per valutare una nuova primitiva di sincronizzazione. Ancora una volta, in se e per se, è un discorso accademico/teorico. Ci sono contesti in cui bisogna gestire i thread (esempio in un kernel, o in particolari applicazioni semi-embdedded). Su un'applicazione di alto livello, la cosa non funziona, non scala. Non ci sono santi. MySQL ha dimostrato chiaramente come il modello a thread scali male sull'I/O. Ma ci sono un mucchio di esempi. Lo stato condiviso è creare un problema e poi mostrare come si può risolverlo. Il che mi diverte anche quando affronto le cose da un punto di vista teorico *e* mi interessa pure se non ho altra strada. Ma quando posso evitare, lo faccio e basta: tipicamente non ho tempo da perdere. Potrei anche citarti le parole di Van Roy e Haridi. Ormai le ho copia- incollate tante di quelle volte che quasi le so a memoria. <g> > I Thread lavorano su strutture dati > condivise. E in generale il dato condiviso fa parte dello stato del > programma... Solo ed esclusivamente se uno vuole cattive performance e divertirsi a debuggare race conditions e altri heisenbugs. In particolare il modo più naturale per lavorare fra thread è precisamente quello del passaggio di messaggi. Nota che è qualcosa che ci viene insegnato anche dalla comune esperienza: se devi mettere due persone a lavorare su qualcosa, è bene dividere le responsabilità e fare comunicare, *non* lasciare che mettano le mani nelle stesse cose. Tra l'altro un computer è notevolmente più stupido di un essere umano, per cui non ha il buon senso di non fare certe cose: il tutto resta a carico del programmatore. Programmatore che avrebbe anche di meglio da fare, diciamocelo. > Ma secondo me è più un problema di stile, senz'altre conseguenze > pratiche. A > me pare più pulito usare i thread, certo sarebbe meglio creare un > pool di > thread da riciclare... e forse lo farò, ma di sicuro non è l'obiettivo > principale dell'esame. E sbagli: il punto chiave è che proprio il meccanismo a thread non è particolarmente adatto. Non solo, in un mondo in cui si va verso il grid-computing, è pure anacronistico. Hai due modi efficienti di gestire la cosa: 1. usare la programmazione asincrona (ma gestirla a basso livello è una rogna, specie se devi ben intervallare compiti di calcolo e compiti di I/O. 2. usare un modello a processi. In questo caso è tutto *assolutamente* banale. Hai un processo 'padre' che coordina il tutto e dei processi figli che chiedono informazioni su cosa eseguire. Lanciare processi in unix (e anche farlo con python) è qualcosa di oltremodo poco costoso. Ma tu tra l'altro non vuoi veramente lanciare una caterva di processi. Diciamo 5 processi (contando il padre). O 9. O un numero che piace a te. Il padre (possibilmente in maniera asincrona -- ma a questo punto è abbastanza facile anche senza oggetti di alto livello) ascolta i figli. Questi danno informazioni e prendono ordini. Il padre ha l'informazione 'totale' e quando si ha finito risponde. > Per la cosa del proff, dovrebbe essere abbastanza tranquillo, di > solito se > (raramente!) non capiscono qualcosa non pensano che sia sbagliato, > ma anzi > si complimentano di aver usato cose nuove e di avergliele fatte > scoprire :-) Sarai fortunato, vah. > Comunque, per quanto sia un confronto che mi stimola, forse è meglio > non > farlo su questa ml ( mano che gli admin non siano un po' elastici :-D) Gli 'admin' non saprei neppure dire chi sono, in effetti. Cioè quelli 'fisici' direi di si, quelli 'spirituali' non so più come si situa la ML rispetto a python.it e di conseguenza rispetto a Python Foundation. Ad ogni modo ti garantisco io di persona personalmente che non ci sono problemi e si può proseguire. Anche non volendo *siamo* IT. _______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python