Software buffert auf einmal Output- python- o. linuxbedingt?

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Antworten
ivka_sto
User
Beiträge: 63
Registriert: Dienstag 11. Dezember 2007, 23:13

Hallo Leute,

Ich steh vor einem Problem, wobei ich an mehreren Stellen mit Unklarheiten kämpfen muß, und ich weiß nicht, ob spekulative Annahmen die Sache wirklich voranbringen, also frag ich mal :wink:

Und zwar, ich starte über Python eine Simulationssoftware mit popen, die Software rechnet ne Zeit lang, und schreibt die Ergebnisse, wobei der Output aus mehreren Dateien besteht. Die Software buffert aber normalerweise nicht, soll heißen - die sollte ihre Berechnungen schon beim Rechnen speichern, anstatt daß man nach Beenden der Anwendung noch 5 min wartet, bis der Output noch geschrieben wird.

Und jetzt meine Schwierigkeit: Ich kann leider nicht so genau beurteilen, an welcher Stelle ich arbeiten müßte - ist es möglicherweise ein Problem bedingt durch Python, daß der Output künstlich gebuffert wird, oder kann es auch an irgendeinem internen Linux-Verwaltungstool liegen, oder eben was ganz anderes, was ich nciht beachtet habe?
Hilfreich wäre schon, wenn jemand eine Idee hätte, wie ich es rausfinden könnte :)

Vielen Dank im voraus,
ivka_sto
ms4py
User
Beiträge: 1178
Registriert: Montag 19. Januar 2009, 09:37

``popen`` ist deprecated. Nutze das subprocess-Modul.
Damit kannst du auch warten, bis der gestartete Prozess beendet ist und mit PIPES mit dem Prozess kommunizieren.

Deine Beschreibung ist leider ein bisschen unklar, es wird nicht deutlich, wann du mit dem Lesen der Dateien beginnen willst und wann die Dateien letztendlich von dem Prozess geschrieben werden.
CM
User
Beiträge: 2464
Registriert: Sonntag 29. August 2004, 19:47
Kontaktdaten:

Hoi,

popen? Ich hoffe Du meinst subprocess.Popen? Zeig mal etwas Code, damit man evtl. das Problem einschätzen kann.

Gruß,
Christian

edit: Viel zu langsam ...
Benutzeravatar
Rebecca
User
Beiträge: 1662
Registriert: Freitag 3. Februar 2006, 12:28
Wohnort: DN, Heimat: HB
Kontaktdaten:

Die Aus-/Eingabe wird natuerlich vom Betriebssystem schon gepuffert. Wenn du also einen Prozess haettest, der viel rauschreibt, sodass der Puffer irgendwann voll ist, wuerde das Programm solange unterbrochen, bis wieder Platz im Puffer ist. Du musst also dafuer sorgen, dass du die Daten auch liest. Inwiefern das jetzt zu deiner Problembeschreibung passt, ist mir aber aus deinem Post auch nicht so ganz klar geworden.
Offizielles Python-Tutorial (Deutsche Version)

Urheberrecht, Datenschutz, Informationsfreiheit: Piratenpartei
ivka_sto
User
Beiträge: 63
Registriert: Dienstag 11. Dezember 2007, 23:13

Hallo :)

Doch, klar, subprocess.Popen, hab mich vertippt.

@ice2k3: Ich würde am liebsten mit dem Lesen schon sofort anfangen, nachdem die Berechnungen ausgeführt sind, doch ich muß darauf warten, daß sie erst nach vollständigem Beenden der Anwendung geschrieben werden. Also hronologisch -
aktuell: Rechnen - Fertig - Schreiben - Lesen
gewünscht: Rechnen - Schreiben - Lesen - Fertig

@CM: An dem Code ist nichts Auffälliges dran, so nach dem Motto

Code: Alles auswählen

simu = subprocess.popen(cmd, stderr = subprocess.PIPE)
simu.wait()
out_file = open('soundso', 'r')
out_content = out_file.readlines()
out_file.close()
for i in range (-1, -5, -1):
   k = out_content[i].strip()
   if (k.find('ExitNum') != -1):
      print 'exit number: ' + str(k[34:]).strip()
   else:
      pass
@Rebecca: Weißt du eventuell ob es eine Möglichkeit gibt, die Größe des Puffers in Linux manuell zu stellen? Es ist tatsächlich so, daß das Programm riesige Datensätze ausschreibt - wäre besser, wenn sich der Weg über das Betriebssystem möglichst transparent gestalten ließe.

Vielen Dank für die Antworten :)
BlackJack

@ivka_sto: Da kannst Du nichts dran ändern, solange Dir die Simulationssoftware keine Möglichkeiten dafür gibt. Das ist eine Sache zwischen ihr und dem Betriebsystem.

Mit `stderr` von der Simulation kannst Du Probleme bekommen. Wenn Du eine Pipe erstellst, dann musst Du die Ausgaben da auch lesen, sonst kann es schnell mal passieren, dass alles "hängenbleibt", wenn das Simulationsprogramm nicht weitermachen kann und darauf wartet, dass die Ausgabe abgenommen wird, während Dein Programm darauf wartet, dass die Simulation beendet ist.

Die ``for``-Schleife und was da drin ist, sieht übrigens etwas gewöhnungsbefürftig aus. Den Index `i` könnte man sich sparen, die sinnlosen Klammern um die Bedingung, `find()` und den Vergleich auf -1 auch, und natürlich auch den leeren ``else``-Zweig und den `str()`-Aufruf auf etwas das sowieso schon eine Zeichenkette ist. Und `k` ist ein nichtssagender Name.

Code: Alles auswählen

for line in reversed(out_content[-5:]):
    if 'ExitNum' in line:
        print 'exit number:', line[34:].strip()
ivka_sto
User
Beiträge: 63
Registriert: Dienstag 11. Dezember 2007, 23:13

Wow, danke sehr, das sieht wirklich viel besser aus. Bzgl dem leeren else: Ich glaube irgendwo gelesen zu haben, dass es für eine bessere Übersichtlichkeit und Lesbarkeit wichtig sei, bei fehlender else-Bedingung das else mit einem pass trotzdem stehen zu lassen. Nun kann ich schlecht beurteilen, wie lesbar mein eigener Code ist - rätst du grundsätzlich von dem else: pass ab?

Noch was - auch wenn es eine Frage zw. Simulationssoftware und BS ist - ließe sich nicht eventuell über das BS darauf wirken?

Viele Grüße,
ivka_sto
BlackJack

@ivka_sto: Ich würde von ``else: pass`` grundsätzlich abraten. Das macht es IMHO unübersichtlicher und ich frage mich immer wenn ich sowas sehe, was das da soll. Ob das Absicht ist, oder ob es ein Platzhalter für Code ist, der da noch fehlt.
Antworten