[Python] Decorated Concurrency - Python multiprocessing made really really easy

[alessandro medici]

Il giorno 21 maggio 2016 12:51, enrico franchi <enrico.franchi a gmail.com>
ha scritto:

>
>
> 2016-05-20 13:59 GMT+01:00 alessandro medici <alexxandro.medici a 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
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20160521/e24dc8e7/attachment.html>