Python: multiprocessing.anzeigen: Wenn ein Prozess eine Ausnahme auslöst, warum sind nicht andere Prozesse' finally-Blöcke genannt?

Mein Verständnis ist, dass endlich Klauseln muss *immer* ausgeführt werden, wenn die versuchen, eingegeben wurde.

import random

from multiprocessing import Pool
from time import sleep

def Process(x):
  try:
    print x
    sleep(random.random())
    raise Exception('Exception: ' + x)
  finally:
    print 'Finally: ' + x

Pool(3).map(Process, ['1','2','3'])

Erwartete Ausgabe ist, dass für jedes x welches gedruckt wird, auf seine eigene, indem Sie die Linie 8, es muss werden, ein vorkommen von 'Endlich x'.

Beispiel-Ausgabe:

$ python bug.py 
1
2
3
Finally: 2
Traceback (most recent call last):
  File "bug.py", line 14, in <module>
    Pool(3).map(Process, ['1','2','3'])
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/multiprocessing/pool.py", line 225, in map
    return self.map_async(func, iterable, chunksize).get()
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/multiprocessing/pool.py", line 522, in get
    raise self._value
Exception: Exception: 2

Scheint es, dass eine Ausnahme die Beendigung eines Prozesses beendet die Eltern und Geschwister Prozesse, auch wenn es weitere Arbeit erforderlich zu tun, die in anderen Prozessen.

Warum bin ich da falsch? Warum ist dies richtig? Wenn dies korrekt ist, wie sollte man sicher bereinigen von Ressourcen, die in Multiprozess-Python?

InformationsquelleAutor Daniel Wagner-Hall | 2011-10-09
  1. 33

    Kurze Antwort: SIGTERM Trumpf finally.

    Lange Antwort: Aktivieren Sie die Protokollierung mit mp.log_to_stderr():

    import random
import multiprocessing as mp
import time
import logging

logger=mp.log_to_stderr(logging.DEBUG)

def Process(x):
    try:
        logger.info(x)
        time.sleep(random.random())
        raise Exception('Exception: ' + x)
    finally:
        logger.info('Finally: ' + x)

result=mp.Pool(3).map(Process, ['1','2','3'])

    Die logging-Ausgabe enthält:

    [DEBUG/MainProcess] terminating workers

    Entspricht diesen code in multiprocessing.pool._terminate_pool:

        if pool and hasattr(pool[0], 'terminate'):
        debug('terminating workers')
        for p in pool:
            p.terminate()

    Jeder p im pool ist ein multiprocessing.Process und die Berufung terminate (zumindest auf nicht-Windows-Rechner) ruft SIGTERM:

    vom multiprocessing/forking.py:

    class Popen(object)
    def terminate(self):
        ...
            try:
                os.kill(self.pid, signal.SIGTERM)
            except OSError, e:
                if self.wait(timeout=0.1) is None:
                    raise

    So kommt es zu dem, was passiert, wenn ein Python-Prozess in einem try suite gesendet SIGTERM.

    Betrachten Sie das folgende Beispiel (test.py):

    import time    
def worker():
    try:
        time.sleep(100)        
    finally:
        print('enter finally')
        time.sleep(2) 
        print('exit finally')    
worker()

    Wenn Sie es ausführen, dann senden Sie eine SIGTERM, dann endet der Prozess sofort, ohne Eingabe der finally suite, wie gezeigt, indem Sie keine Ausgabe und keine Verzögerung.

    In einem terminal:

    % test.py

    Im zweiten terminal:

    % pkill -TERM -f "test.py"

    Ergebnis im ersten terminal:

    Terminated

    Vergleichen Sie das mit, was passiert, wenn der Prozess gesendet wird, eine SIGINT (C-c):

    Im zweiten terminal:

    % pkill -INT -f "test.py"

    Ergebnis im ersten terminal:

    enter finally
exit finally
Traceback (most recent call last):
  File "/home/unutbu/pybin/test.py", line 14, in <module>
    worker()
  File "/home/unutbu/pybin/test.py", line 8, in worker
    time.sleep(100)        
KeyboardInterrupt

    Fazit: SIGTERM Trumpf finally.

    InformationsquelleAutor unutbu
  2. 4

    Den Antwort von unutbu definitiv erklärt warum Sie erhalten das Verhalten, das Sie beobachten. Es sollte jedoch betont werden, dass SIGTERM gesendet wird, nur weil, wie multiprocessing.pool._terminate_pool umgesetzt wird. Wenn Sie können vermeiden Sie die Verwendung Pool, dann können Sie die Verhalten, die Sie wünschen. Hier ist ein entlehnt Beispiel:

    from multiprocessing import Process
from time import sleep
import random

def f(x):
    try:
        sleep(random.random()*10)
        raise Exception
    except:
        print "Caught exception in process:", x
        # Make this last longer than the except clause in main.
        sleep(3)
    finally:
        print "Cleaning up process:", x

if __name__ == '__main__':
    processes = []
    for i in range(4):
        p = Process(target=f, args=(i,))
        p.start()
        processes.append(p)
    try:
        for process in processes:
            process.join()
    except:
        print "Caught exception in main."
    finally:
        print "Cleaning up main."

    Nach dem senden eines SIGINT ist, Beispiel Ausgabe:

    Caught exception in process: 0
^C
Cleaning up process: 0
Caught exception in main.
Cleaning up main.
Caught exception in process: 1
Caught exception in process: 2
Caught exception in process: 3
Cleaning up process: 1
Cleaning up process: 2
Cleaning up process: 3

    Beachten Sie, dass die finally Klausel lief für alle Prozesse. Wenn Sie brauchen, shared memory, sollten Sie die Verwendung Queue, Pipe, Manager oder externen speichern wie redis oder sqlite3.

    InformationsquelleAutor Tom
  3. 1

    finally wieder stellt sich die ursprüngliche Ausnahme es sei denn, Sie return aus es. Die Ausnahme wird dann angehoben, durch Pool.map und tötet die gesamte Anwendung. Die Teilprozesse beendet sind, und Sie sehen keine anderen Ausnahmen.

    Können Sie ein return zu schlucken Ausnahme:

    def Process(x):
  try:
    print x
    sleep(random.random())
    raise Exception('Exception: ' + x)
  finally:
    print 'Finally: ' + x
    return

    Dann sollten Sie None in Ihrem map Ergebnis, wenn eine Ausnahme aufgetreten ist.

    • Dies ist eine nützliche Abhilfe, aber sicher ist in jedem Fall die Laufzeit sollte nicht erlaubt werden, getötet werden, bis alle finally-Blöcke ausgeführt wurden?
    • Wagner-Halle: Pool.map nachempfunden ist map, das endet auch, wenn die Funktion zugeordnet, wirft eine exception. Vielleicht (ausprobieren) die Kind-Prozesse beendet sind, normalerweise und tatsächlich führen die finally - nur weil dein main-thread getötet wird zuerst der Ausgang von den Kindern nicht mehr Lesen.
    InformationsquelleAutor Jochen Ritzel
Schreibe einen Kommentar