Alternatywne wzorce użycia dla multiprocessingu Pythona unikające proliferacji globalnego stanu?

Ten (bardzo uproszczony przykład) działa dobrze (Python 2.6.6, Debian Squeeze):

<code>from multiprocessing import Pool
import numpy as np

src=None

def process(row):
    return np.sum(src[row])

def main():
    global src
    src=np.ones((100,100))

    pool=Pool(processes=16)
    rows=pool.map(process,range(100))
    print rows

if __name__ == "__main__":
    main()
</code>

jednak po latach naukiglobalny stan zły !!!, wszystkie moje instynkty mówią mi, że naprawdę wolałbym raczej napisać coś bliższego:

<code>from multiprocessing import Pool
import numpy as np

def main():
    src=np.ones((100,100))

    def process(row):
        return np.sum(src[row])

    pool=Pool(processes=16)
    rows=pool.map(process,range(100))
    print rows

if __name__ == "__main__":
    main()
</code>

ale oczywiście to nie działa (odkłada słuchawkę, nie mogąc czegoś wyblaknąć).

Przykład tutaj jest trywialny, ale do czasu dodania wielu funkcji „procesowych”, a każda z nich jest zależna od wielu dodatkowych danych wejściowych ... wszystko to przypomina nieco coś napisanego w BASIC 30 lat temu. Próba użycia klas do przynajmniej agregacji stanu z odpowiednimi funkcjami wydaje się oczywistym rozwiązaniem, alenie wydaje się takie łatwe w praktyce.

Czy istnieje jakiś zalecany wzorzec lub styl do używania multiprocessing.pool, który pozwoli uniknąć rozprzestrzeniania się globalnego stanu w celu obsługi każdej funkcji, którą chcę odwzorować równolegle?

Jak radzą sobie z tym doświadczeni „profesjonaliści od przetwarzania wieloprocesowego”?

Aktualizacja: Zauważ, że jestem zainteresowany przetwarzaniem znacznie większych tablic, więc wariacje na powyższym, które są marynowanesrc każde wywołanie / iteracja nie są prawie tak dobre jak te, które rozwidlają je w procesach roboczych puli.

questionAnswers(1)

yourAnswerToTheQuestion