Il giorno 21 maggio 2016 12:51, enrico franchi <enrico.fran...@gmail.com> ha scritto:
> > > 2016-05-20 13:59 GMT+01:00 alessandro medici <alexxandro.med...@gmail.com> > : > >> >> - "multiprocessing" implica (a meno di eccezioni notevoli) "pickle di >>> tutto" >>> >> >> ? cioè i dati vengono trasmessi via pickle e non via puntatori? Sure? >> O invece non ho capito cosa affermi? Sorry per la mia ignoranza, ma >> sono anziano e con i capelli MOLTO grigi. >> > > Non e' questione di ignoranza, basta rifletterci. Allora... > multi-*processing*. > Diciamo che e' sano assumere che siano piu' processi, ok? Quindi piu' > processi hanno spazi di indirizzamento separati (visto che sono appunto > processi multipli). Quindi... cosa se ne fa un processo di un puntatore a > uno spazio di indirizzamento a cui non ha accesso? Diciamo nulla? Ah... ma > c'e' la memoria condivisa... ecco, ora riflettiamo anche su questa cosa. > Quando tu scrivi > > foo = Bar() > > tu stai dicendo a Python di creare un oggetto. Bene. Non gli stai dicendo > dove crearlo. Il che vuole dire che non e' in memoria condivisa. > L'alternativa sarebbe immaginare che Python ficcasse *tutto quanto* in > memoria condivisa... > Già. Ho passato buona parte di ieri a guardarmi proprio il funzionamento del Manager dei processi. Ed ho lasciato a metà quello sul funzionamento di pickle. Il ragionamento che fai fila, però... Mettiamola così: mi piacerebbe che esistesse un'opzione tale che permettesse di definire una variabile in uno spazio condiviso ed accessibile direttamente dai singoli processi. Starebbe poi a me gestirla. E sicuramente in molti casi sarebbe più veloce che impacchettare e spacchettare in giro dati che, magari, servono solo in lettura. Poi, se voglio darmi da solo la zappa sui piedi, sono affari miei, in pura logica Python :-) Questo al di là della gestione bufferizzata dei dati elaborati da pickle e dalle sue piccole (tutto sommato) limitazioni. > il che vorrebbe anche dire che ogni singolo pezzo di dato di Python > dovrebbe avere qualche lock che lo protegge... altro che GIL: avremmo gia' > threading granulare [ah, certo, potremmo anche immaginare che schiaffa > tutto in memoria condivisa e c'e' un GIL su questo... ma allora fare > multithreading o multiprocessing in Python dovrebbe essere uguale, cosa che > no ne']. > No. Non occorrerebbe per tutto. Ovvio. > > Segue che ... no, non possono essere semplici puntatori. "Come" viene > fatto non puo' essere derivato da principi primi. E si, effettivamente e' > Pickle. > > Per inciso... presente il Manager di multiprocessing (e tutta la parte di > "memoria condivisa" di multiprocessing)? > Bene... di condiviso non c'e' nulla. Funziona con scambio di messaggi > (cioe' piglia gli oggetti, li serializza e li spara in giro). Insomma, e' > un giocattolino che e' comodo da usare e da ragionarsi come la peggiore > delle memorie condivise ed e' veloce come il piu' lento dei message > passing. Un win win... per i linguaggi concorrenti... > Già e vediamo se ho capito, allora, e uso come esempio proprio il programmino nel sito che aggiorna il dizionario: Lancio da processo padre il processo figlio, al quale vengono passati, pickled via Manager, i dati dei parametri, poi quando il figlio arriva al punto dell'aggiornamento del dizionario il figlio chiama il Manager che pickla i dati di nuovo, li torno al padre (sotto GIL e quindi in lista d'attesa se vi sono altri processi che vogliono fare la stessa cosa) che aggiorna il dizionario e torna il controllo, sempre via Manager al figlio. Corretto? Se è così ora affronterei un multiprocesso con le idee molto più chiare sul cosa, quando, quanto passare al processo stesso e sull'architettura che darei al soft. Quindi grazie a tutti quelli che hanno scritto al riguardo: ho avuto le risposte che cercavo. :-) Alex
_______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python