Ich verwende pyro für die grundlegende Verwaltung paralleler Jobs in einem Rechencluster. Ich bin gerade in einen Cluster umgezogen, wo ich für die Verwendung aller Kerne auf jedem Rechenknoten verantwortlich sein werde. (Bei früheren Clustern war jeder Kern ein separater Knoten.) Das Python-Modul Multiprocessing scheint gut geeignet zu sein Dies. Ich stelle fest, dass es auch für Remote-Prozess-Kommunikation verwendet werden kann. Wenn jemand beide Frameworks für die Remote-Prozess-Kommunikation verwendet hat, wäre ich dankbar zu hören, wie sie aufeinander aufbauen. Der offensichtliche Vorteil des Multiprocessing-Moduls ist, dass es ab 2.6 integriert ist. Abgesehen davon fällt es mir schwer zu sagen, was besser ist.
EDIT: Ich ändere meine Antwort, damit Sie Schmerzen vermeiden. Multiprozessing ist unausgereift, die Dokumente in BaseManager sind FALSCH , und wenn Sie ein objektorientierter Denker sind, der zur Laufzeit Laufzeitobjekte erstellen möchte, PYRO VERWENDEN ODER SIE WERDEN ERNSTSINNEND! Wenn Sie nur funktionale Programmierung mit einer gemeinsamen Warteschlange machen, die Sie im Voraus registrieren, wie all die dummen Beispiele GUT FÜR SIE.
Mehrfachverarbeitung:
Pyro:
Bearbeiten: Als ich das erste Mal antwortete, war ich gerade in 2.6 Multiprocessing getaucht. In dem Code, den ich unten zeige, wird die Texture-Klasse als Proxy registriert und freigegeben, jedoch ist das "Daten" -Attribut innerhalb davon NICHT. Also rate mal, was passiert, jeder Prozess hat eine separate Kopie des Attributs "data" innerhalb des Texture-Proxy, trotz allem, was du erwartest. Ich habe gerade unzählige Stunden damit verbracht, herauszufinden, wie ein gutes Muster während der Laufzeit gemeinsame Objekte erzeugen kann, und ich lief immer wieder in die Wände. Es war ziemlich verwirrend und frustrierend. Vielleicht bin ich es nur, aber wenn ich mir die wenigen Beispiele ansehe, die die Leute versucht haben, sieht es nicht so aus.
Ich muss die schmerzhafte Entscheidung treffen, die Multiprocessing-Bibliothek fallen zu lassen und Pyro so lange zu bevorzugen, bis die Multiprocessing-Methode ausgereifter ist. Während ich anfänglich aufgeregt war, zu erfahren, dass Multiprocessing in Python eingebaut ist, bin ich jetzt völlig angewidert damit und würde lieber das Pyro-Paket viele Male mit Freude installieren, dass eine so schöne Bibliothek für Python existiert.
Ich habe Pyro in vergangenen Projekten benutzt und bin sehr glücklich damit. Ich habe auch begonnen, mit Multiprocessing neu in 2.6 zu arbeiten.
Mit Multiprocessing fand ich es ein wenig peinlich, freigegebene Objekte nach Bedarf erstellen zu lassen. Es scheint, als sei das Multiprocessing-Modul in seiner Jugend mehr auf funktionale Programmierung als auf objektorientierte Programmierung ausgerichtet. Dies ist jedoch nicht ganz richtig, weil es möglich ist, ich fühle mich nur durch die "Register" -Anrufe eingeschränkt.
Zum Beispiel:
manager.py:
%Vor%server.py:
%Vor%client.py:
%Vor%Die Peinlichkeit, die ich beschreibe, kommt von server.py, wo ich eine getTexture-Funktion registriere, um eine Funktion eines bestimmten Namens aus dem TextureManager abzurufen. Wenn ich das hier durchführe, könnte die Ungeschicklichkeit möglicherweise beseitigt werden, wenn ich den TextureManager zu einem Objekt machen würde, das gemeinsam nutzbare Texturen erstellt / abruft. Meh ich spiele immer noch, aber du kommst auf die Idee. Ich kann mich nicht erinnern, mit Pyro auf diese Unbeholfenheit gestoßen zu sein, aber es gibt wahrscheinlich eine Lösung, die sauberer ist als das obige Beispiel.
Tags und Links python rpc multiprocessing pyro