Pipelines

[ravenheart]

Ich möchte gerne mal ein Programm schreiben, das aus mehreren (also am Anfang aus 2) Prozessen besteht, die miteinander kommunizieren.
Nun dachte ich daran Pipes zu verwenden (http://www.python-kurs.eu/pipes.php).

Ist das ein adäquates Mittel?

[Leonidas]

Nein. Man würde dazu eher PyRO (Python Remote Objects) oder eine ähnliche Technologie verwenden. Hängt halt immer ab was du GENAU machen willst.

[ravenheart]

Naja im Grunde eine Pipeline aufbauen.

Ich möchte Objekte haben (für den Anfang vlt einfach Zahlen).
Dann möchte ich Bearbeitungsstufen. Eine Stufe soll ein Item bearbeiten (zB einen konstanten Wert addieren) und zur nächsten Stufe weiterleiten.

Für den Anfang vlt auch einfach ein Producer/Consumer Programm.
Wichtig ist mir nur dass es durch mehrere Prozesse und nicht Threads realisiert wird.

Ziel ist es, dass die Pipeline schneller wird, als wenn ich alle Objekte bearbeite und dann an die nächste Stufe weiterleite.

[BlackJack]

@ravenheart: Wie sieht es mit dem `multiprocessing`-Modul aus der Standardbibliothek aus? Da gibt es auch `Pipe`-Objekte zur Kommunikation.

[ravenheart]

Es gint mir ein paar Pipes zu viele.

Multiprocessing, Subprocess, os.pipe()...

Vor lauter Möglichkeiten weiß ich nicht, was brauchbar ist

[deets]

Es gint mir ein paar Pipes zu viele.

Multiprocessing, Subprocess, os.pipe()...

Vor lauter Möglichkeiten weiß ich nicht, was brauchbar ist

Na, alle. Je nachdem, was du machen willst oder musst. Aber fuer deinen Hausgebrauch multiprocessing oder wie schon von Leonidas erwaehnt Pyro.

[ravenheart]

Hmm , ein kurzer Blick auf Pyro sagt mir, dass es sowas wie RMI ist. Ich dacht, das Ziel von RMI wäre es Klassen in einer Applikation aufzurufen, auch wenn diese auf einem anderen Computer lägen, ohne dass man sich um darum kümmern muss, also es sieht so aus, als wäre die Klasse auf dem lokalen Rechner. Zumindest grob so.

Ist das das, was ich haben will? - Ich erkenne so auf Anhieb nicht , wie genau das meinen Zweck erfüllt.
--- Das liegt wharscheinlich an meiner eigenen Inkompetenz, dass ich das nicht sehe. Ich will keineswegs den Tipp mit Pyro kritisieren. Aber als Neuling ists eben sehr schwierig herauszubekommen, was genau man eigentlich will oder benötigt

[BlackJack]

@ravenheart: Die anderen Klassen müssen ja nicht auf anderen Rechnern liegen, sie können auch auf dem gleichen Rechner in verschiedenen Prozessen existieren. Und wenn dann jeder Prozess ein Teilproblem Deiner "Pipeline" löst, können die ihre Daten mit Pyro-Aufrufen austauschen und jeweils an die nächste Station weiter geben.

[ravenheart]

Und für mich nochmal:

Was ist zB der Unterschied zwischen Pyro und Twisted?

[deets]

Wie kommt denn jetzt twisted in's Spiel?

Wie auch immer... die Unterschiede sind gewaltig. Wie du schon gesagt hast, Pyro ist im Grunde RMI. Und das ist das angenehmste, was man haben kann. Denn dann sieht der Code vereinfacht so aus:

Code: Alles auswählen

remote_object = hole_remote_instanz()
remote_object.uebergebe_daten_zum_prozessieren(serialisierbare_daten)
weitermachen()

Das war's. Das hole_remote_instanz ist ziemlich trivial in Pyro, wenn man zB einen Name-Service hat. Der ganze Lookup-Kram ist nervig, aber im Grunde nicht mehr, als sich IP + port merken zu muessen, oder einen Dateinamen.

Twisted ist ein Netzwerk-Protokol-Stack, mit der Betonung auf asynchronizitaet. Damit kannst du zwar auch Pipes basteln - aber es ist nicht wesentlich komfortabler, als pure sockets. Du bekommst ein paar Standard-Protokolle geschenkt, aber keines davon stellt dir Daten in Python selbst zur Verfuegung - das sind immer alles Strings.

Wenn du nicht darauf angewiesen bist, mit anderen Clients zusammenzuarbeiten (also, Nicht-Python), dann bringt dir Twisted gar nix.