Verzögerte Konsolenausgabe bei Umleitung in File

[Alex.P]

Hallo,

wenn eine DOS-Konsolen Ausgabe umgeleitet wird (z.B. mit CreateProcess und StartupInfo.hStdOutput := StdOutFile)
wird die Ausgabe in das File gepuffert und verzögert blockweise geschrieben.
Das Problem tritt auch schon auf wenn man in der DOS-Konsole die Ausgabe in ein File umleitet (Konsolenprogramm.exe > datei.txt);
Scheint also eigendlich ein Windows Problem zu sein.

Gibt es eine Möglichkeit die Buffergröße kleiner zu setzten oder dem Prozess einen Flash Aufforderung zu schicken?

Grüße
Alex

[himitsu]

Selbst wenn (was standardmäßig der Fall ist) StdOutFile, welches z.B. via CreateFile erstellt wurde, über die WindowsFileCache gepuffert wird, so kann man dennoch sofort drauf zugreifen, da beim Auslesen zuerst die Cache gelesen wird.

Die alte TextFile (AssignFile) von Delphi nutzt aber einen Puffer, welchen man nicht von ausen beeinflussen kann, aber in Richtung "Bildschirm" (Write/Writeln über die Standardausgabe) sollte nichts gepuffert werden.

Was die Command-Shell intern "optimiert, weiß ich nicht und auch da wird man von ausen nichts machen können.



Wie hast du bei CreateProcess die Umleitung eingerichtet
und wie prüfst du, ob/daß die Daten sofort/verzögert ankommen?

[Alex.P]

Das Textfile bleibt leer bis eine gewisse Anzahl Zeichen gesammelt ist, oder das Programm beendet wurde.
Egal ob ich es mit AssignFile öffne oder direkt im Editor beobachte.

Das befüllen des Files ist stark vom Programm abhängig.
Manche schreiben ohne merkliche Zeitverzögerung ins File und andere Konsolenprogramme warten bis sie 3000 bis 4000 Chars beisammen haben. Obwohl sie die Ausgabe direkt in der Konsole sofort anzeigen. Womöglich ist die Anwendung auch nur sauschlecht programmiert.

Vielleicht kann man in der Registry irgendwas drehen, oder dem Prozess dazu überreden seinen Cache vorzeitig zu leeren.

Hier mal das relevante aus meinem Code:

Delphi-Quellcode:

  StdOutFile := CreateFile (PChar(StdOutFn), FILE_SHARE_READ or  GENERIC_WRITE,
                FILE_SHARE_READ or FILE_SHARE_WRITE, @SecAttrib, CREATE_ALWAYS,
                FILE_ATTRIBUTE_TEMPORARY or FILE_FLAG_WRITE_THROUGH, 0);


  with StartupInfo do
  begin
    cb          := SizeOf(StartupInfo);
    dwFlags     := STARTF_USESHOWWINDOW or STARTF_USESTDHANDLES;
    wShowWindow := SW_HIDE;
    lpTitle := ConsoleName;
    hStdInput := GetStdHandle (STD_INPUT_HANDLE);
    hStdError := StdOutFile;
    hStdOutput := StdOutFile;
  end;

  if CreateProcess(nil,
    zAppName,
    nil,
    nil,
    true,
    NORMAL_PRIORITY_CLASS,
    nil,
    PWideChar(WorkDir),
    StartupInfo,
    ProcessInfo) then

[hoika]

Hallo,

wie sieht es dann mit FILE_FLAG_NO_BUFFERING aus ?

StdOutFile := CreateFile (PChar(StdOutFn), FILE_SHARE_READ or GENERIC_WRITE,
FILE_SHARE_READ or FILE_SHARE_WRITE, @SecAttrib, CREATE_ALWAYS,
FILE_ATTRIBUTE_TEMPORARY or FILE_FLAG_WRITE_THROUGH or FILE_FLAG_NO_BUFFERING, 0);


Heiko

[Alex.P]

Hört sich gut an, bringt aber keine Änderung

[himitsu]

Bei FILE_FLAG_NO_BUFFERING muß in ganzen Sektoren zugegriffen werden und das kannst du bei externen Zugriffen nicht sicherstellen.

FILE_FLAG_WRITE_THROUGH sagt nur, daß die Daten sofort, quasi an der WFC vorbei, in die Datei geschrieben werden soll.

Aber wie gesagt, wenn etwas in der WFC liegt, dann ist es auch so schon auslesbar.
Dieses bremst also nur unnötig die Verarbeitung ab.

Diese Beiden lohnen sich erst, wenn entweder viele Daten verarbeitet werden, welche die WFC überlasen und zuviel RAM belegen würden.
Oder wenn z.B. bei einem Systemabsturz/Stromausfall möglichst keine Daten verloren gehen sollen.


Tja, hier scheint es wohl so zu sein, daß einige/viele Programme (das Delphi-Write übrigens auch) zu prüfen scheinen, wo die Daten hingehn und wen es nicht zur Anzeige soll, dann verwenden sie wohl einen internen Puffer (also noch vor der WinAPI WriteFile).
Wenn das nun so ist, dann wirst du da wohl auch nichts dran ändern können.

[shmia]

Du wartest doch bestimmt bis der Child-Prozess beendet ist.
Kannst du während des Wartens nicht immer mal wieder FlushFileBuffers(StdOutFile) aufrufen?

Zitat:

...hier scheint es wohl so zu sein, daß einige/viele Programme (das Delphi-Write übrigens auch) zu prüfen scheinen, wo die Daten hingehn...

Dann sieht's schlecht aus.

[himitsu]

FlushFileBuffers ist nur ein nachträgliches FILE_FLAG_WRITE_THROUGH ... wie gesagt, dieses hat nur auf die windowsseitigen Dateipuffer eine Wirkung, welche hier aber kein Problem darstellen können.