Software puffert auf einmal Output - linuxbedingt?

[ivka_sto]

Das, was nach wait() steht (also das Lesen der Files) kommt an einer anderen Stelle, und der Code dazwischen hat mit meiner Frage nichts zu tun, deshalb hab ich den weggelassen.

Es interessiert mich wirklich nur, ob es sich über Linux darauf wirken ließe, daß die Simulationssoftware erst nach Beenden der Simulation das Output schreibt.
communicate kommt aus anderen Gründen nicht in Frage.

Viele Grüße,
ivka_sto

 

[Enumerator]

Hi!

Hast Du die Simulationssoftware mal "von Hand" gefüttert und Dich vergewissert, dass Sie erst gegen Ende des Prozesses Daten schreibt?

Gruß
Enum

 

[deepthroat]

Nein, auch nicht. Es stört mich, das der Output erst geschrieben wird, wenn die Simulationssoftware fertig gerechnet hat. Gerade weil einer der Entwickler gesagt hat, daß das untypisch sei, und es selber womöglich auf Linux geschoben hat - er hat gesagt, normalerweise wird der Output parallel mit dem Rechnen geschrieben. Dann könnte ich schon im Laufe der Rechnung einen Fehler erkennen, sonst rechnet das Programm weiter.

Nein könntest du nicht. Das Programm rechnet ja in jedem Fall weiter da du auf die Beendigung des Programmes wartest. Also irgendwas stimmt da mit deinem Ansatz überhaupt nicht.

Und wie soll ein Programm nach der Beendigung noch irgendwas schreiben?

Wie überprüfst du denn das es erst später schreibt? Welches Dateisystem wird da eingesetzt?

Gruß

 

[ivka_sto]

@deepthroat:
Doch, könnte ich schon. Wenn ich zur Laufzeit des Programms überprüfen kann, ob eine Fehlermeldung ausgegeben worde ist, werd ich auf das wait() natürlich verzichten. Nach Beendigung des Rechnens, nicht nach Beendigung des Programms.
Sorry, wie soll ich rausfinden, welches File-System eingesetzt wird?

@Enumerator:
Ja, tut es trotzdem. Ich hab es auch manuell über die Konsole gestartet, kommt aufs Gleiche raus. Und zwar, es ist ein pid-File vorhanden, solange das Programm rechnet - solange wird nichts geschrieben. Dann verschwindet diese PID aus der Liste der aktuellen Prozesse, und gleich werden die Files unter einer anderen PID geschrieben. Ich denke, das Programm rechnet, bricht kurz ab, und schreibt dann den Output, der solange gepuffert worden ist. Anders kann ich es mir nicht erklären.

 

[Raubkopierer]

Das ganze hängt in meinen Augen wirklich mit den IO-Scheduler des Kernels zusammen, der die Vorgänge entsprechend optimiert. Deshalb haben FDs ja auch die Methode flush() mit der man das Schreiben erzwingen kann.
An deiner Stelle würde ich einmal meine Codevariante testen, die von diesem Problem verschont bleiben sollte (zusätzlich gibt es in der Python Referenz noch einen Hinweis, dass wait() u.U. blockierend wirken kann wodurch dein Problem erklärt werden könnte. Stattdessen wird zu communicate() geraten).

Weiter wäre es wirklich gut zu wissen um welche Software es sich konkret handelt, damit man womöglich selbst einmal testen kann.

Edit: Zur Frage des Dateisystems: Selbiges ist für den Zeitpunkt des Schreibens vollkommen unerheblich. Ich weiß schon, dass ihr auf Systeme wie ReiserFS und XFS hinaus wollt, die in bestimmten Zyklen schreiben doch das sollte durch die Planung des Kernels keinen Einfluss auf das Auslesen besagter Daten haben. Wiederrum wird dies durch die Nutzung von communicate() und dem Verzicht auf jegliche File-Objects komplett eleminiert.

Gerade weil einer der Entwickler gesagt hat, daß das untypisch sei, und es selber womöglich auf Linux geschoben hat - er hat gesagt, normalerweise wird der Output parallel mit dem Rechnen geschrieben. Dann könnte ich schon im Laufe der Rechnung einen Fehler erkennen, sonst rechnet das Programm weiter.

Die Erklärung scheint recht mangelhaft zu sein von Seiten des Programmierers zumindestens was die fachliche Richtigkeit anbelangt. Ich bezweifel, dass er Threads benutzt (Threads sind pfui etc. )um eine wirkliche Paralellisierung zu erreichen. Außerdem kommt hinzu, dass er fahrlässig die Verantwortung von sich weiß obwohl er womöglich einfach oben genanntes "flush" seiner Sprache vergessen hat. Natürlich sind das nur Vermutungen.

 

[deepthroat]

Also, das hat so keinen Sinn. Bisher ist das alles nur ein einziger Wust von Informationshäppchen die uns hier rumraten lassen.

Erzähle uns erstmal genau was da passiert, welche Ausgabe erzeugt wird und was du dann wann machen willst.

Wie arbeitet das Programm? Welches Programm rechnet, welches simuliert, was wird wo aufgerufen? Welche Ausgabe willst du verarbeiten, wie sieht es zur Laufzeit aus?

Gruß