Low Level File I/O --> Interne Datenstrukturen zerstört
Moderator: Moderatoren
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2517
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Low Level File I/O --> Interne Datenstrukturen zerstört
Hallo zusammen
ich habe eine neue Funktion erstellt. Diese nutzt intensiv die Low-Level File Funktionen FOpen() FRead() FWrite() FSeek() FClose() in mehreren unterschiedlichen Threads im selben Programm auf lokale Dateien auf einem Server 2019.
Thread1 öffnet, schreibt in die Datei und schliesst die Datei sofort im Intervall von 1-5 Sek. Dieser Thread ist der einzige der in die Datei SCHREIBT.
Thread2....X öffnen, lesen und schliessen die Datei auch sofort.
Obwohl alles eigentlich perfekt funktionert kommt es sehr häufig, vorallem wenn mehrere Threads lesen, zum Fehler "Interne Datenstrukturen zerstört" in irgend einem Thread der wird dann neu gestartet. Dennoch arbeitet das Programm nicht mehr korrekt "frisst" Speicher und muss zwingend neu gestartet werden.
Kennt jemand die mögliche Ursache? Abhilfe? Sind die Low-Level Funktionen überhaupt für obige Aufgabe geeignet?
Das merkwürde dabei ist: Lässt Thread1 (der Schreibende) die Datei durchgehend geöffnet ist das Problem nicht vorhanden. Die anderen Threads können Stresstest mässig auf der Datei rummachen, nichts geschieht. Schliesst auch Thread1 die Datei dauerts oft nur Sekunden bis zum Crash.
Leider sind die Windows API Funktionen aus dem Kernel nicht so ganz einfach zu nutzen ... das wäre ein Versuch wert ...
ich habe eine neue Funktion erstellt. Diese nutzt intensiv die Low-Level File Funktionen FOpen() FRead() FWrite() FSeek() FClose() in mehreren unterschiedlichen Threads im selben Programm auf lokale Dateien auf einem Server 2019.
Thread1 öffnet, schreibt in die Datei und schliesst die Datei sofort im Intervall von 1-5 Sek. Dieser Thread ist der einzige der in die Datei SCHREIBT.
Thread2....X öffnen, lesen und schliessen die Datei auch sofort.
Obwohl alles eigentlich perfekt funktionert kommt es sehr häufig, vorallem wenn mehrere Threads lesen, zum Fehler "Interne Datenstrukturen zerstört" in irgend einem Thread der wird dann neu gestartet. Dennoch arbeitet das Programm nicht mehr korrekt "frisst" Speicher und muss zwingend neu gestartet werden.
Kennt jemand die mögliche Ursache? Abhilfe? Sind die Low-Level Funktionen überhaupt für obige Aufgabe geeignet?
Das merkwürde dabei ist: Lässt Thread1 (der Schreibende) die Datei durchgehend geöffnet ist das Problem nicht vorhanden. Die anderen Threads können Stresstest mässig auf der Datei rummachen, nichts geschieht. Schliesst auch Thread1 die Datei dauerts oft nur Sekunden bis zum Crash.
Leider sind die Windows API Funktionen aus dem Kernel nicht so ganz einfach zu nutzen ... das wäre ein Versuch wert ...
Valar Morghulis
Gruss Carlo
Gruss Carlo
- Lewi
- 1000 working lines a day
- Beiträge: 830
- Registriert: Di, 07. Feb 2006 14:10
- Wohnort: Hamburg
- Danksagung erhalten: 2 Mal
Re: Low Level File I/O --> Interne Datenstrukturen zerstört
Hallo Carlo,
das Problem liegt im konkurrierenden Schreiben in eine Datei oder beim Lesen von Daten aus einer Datei, die gerade beschrieben wird. Eine zu beschreibende Datei muss im mit dem Parameter -w aufgerufen werden. Betriebssystemsseitig führt es dann zu Problemen, wenn von mehreren Threads versucht wird, gleichzeitig in diese Datei schreiben.
Ein Lösungsansatz wäre, das Schreiben in einem separaten Thread (Wright-Thread) auszulagern, der andere Threads (die nur lesenden Zugriff auf die zu beschreibene Datei haben) über die Signal()-Methode mitteilt, ob ein Schreiben in die Datei aktuell möglich ist. Falls nicht, solange zu warten, bis vom „Write-Thread“ das „ok“ kommt. Über die ::cargo Instanz-Variable könnte die zu schreibenden Daten eines Threads an den Wright-Thread weiter gereicht werden.
Mann konnte über die Signal()-Mehode auch lesende Threads mitteilen, das aktuell ein "Write" ausgeführt. Solange dies der Fall, sollte auch ein lesender Zugriff unterbunden werden.
Viele Grüße
Olaf
das Problem liegt im konkurrierenden Schreiben in eine Datei oder beim Lesen von Daten aus einer Datei, die gerade beschrieben wird. Eine zu beschreibende Datei muss im mit dem Parameter -w aufgerufen werden. Betriebssystemsseitig führt es dann zu Problemen, wenn von mehreren Threads versucht wird, gleichzeitig in diese Datei schreiben.
Ein Lösungsansatz wäre, das Schreiben in einem separaten Thread (Wright-Thread) auszulagern, der andere Threads (die nur lesenden Zugriff auf die zu beschreibene Datei haben) über die Signal()-Methode mitteilt, ob ein Schreiben in die Datei aktuell möglich ist. Falls nicht, solange zu warten, bis vom „Write-Thread“ das „ok“ kommt. Über die ::cargo Instanz-Variable könnte die zu schreibenden Daten eines Threads an den Wright-Thread weiter gereicht werden.
Mann konnte über die Signal()-Mehode auch lesende Threads mitteilen, das aktuell ein "Write" ausgeführt. Solange dies der Fall, sollte auch ein lesender Zugriff unterbunden werden.
Viele Grüße
Olaf
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2517
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: Low Level File I/O --> Interne Datenstrukturen zerstört
Hallo Olaf
Das ist bereits beinahe so wie du schreibst.
Thread 1 öffnet als einiger die Datei für Lesen und Schreiben und ist SYSTEMWEIT die EINZIGE Funktion welche die Datei R/W öffnet und in diese schreibt. Alle der so benutzen Dateien werden im voraus in voller Länge ( 700 MB pro Datei) mit dem benötigten Dateiinhalt (Raster) generiert und vorbereitet. Die Dateilänge ändert danach nie mehr. Es werden vom Thread 1 nur noch bestimmte Positionen überschieben.
ALLE anderen Funktionen und Operation öffnen die Datei nur Lesend ein Schreibzugriff kann absolut ausgeschlossen werden.
Das ist bereits beinahe so wie du schreibst.
Thread 1 öffnet als einiger die Datei für Lesen und Schreiben und ist SYSTEMWEIT die EINZIGE Funktion welche die Datei R/W öffnet und in diese schreibt. Alle der so benutzen Dateien werden im voraus in voller Länge ( 700 MB pro Datei) mit dem benötigten Dateiinhalt (Raster) generiert und vorbereitet. Die Dateilänge ändert danach nie mehr. Es werden vom Thread 1 nur noch bestimmte Positionen überschieben.
ALLE anderen Funktionen und Operation öffnen die Datei nur Lesend ein Schreibzugriff kann absolut ausgeschlossen werden.
Valar Morghulis
Gruss Carlo
Gruss Carlo
- Lewi
- 1000 working lines a day
- Beiträge: 830
- Registriert: Di, 07. Feb 2006 14:10
- Wohnort: Hamburg
- Danksagung erhalten: 2 Mal
Re: Low Level File I/O --> Interne Datenstrukturen zerstört
Wird die Datei nach dem Schreiben geschlossen?
- Lewi
- 1000 working lines a day
- Beiträge: 830
- Registriert: Di, 07. Feb 2006 14:10
- Wohnort: Hamburg
- Danksagung erhalten: 2 Mal
Re: Low Level File I/O --> Interne Datenstrukturen zerstört
Ein fWrite() schreibt die Daten nicht auf den Datenträger sondern in einen Puffer. Erst mit einem fclose(nFileHandle) werden die Puffer physikalisch auf den Datenträger geschrieben.
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2517
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: Low Level File I/O --> Interne Datenstrukturen zerstört
Hallo Lewi
nein die Datei wird nach dem Schreiben nicht geschlossen, wenn Sie geschlossen wird treten sofort die Probleme auf.
Die anderen Threads mit eigenen Filehandles sehen aber mit fread() die änderungen sofort.
nein die Datei wird nach dem Schreiben nicht geschlossen, wenn Sie geschlossen wird treten sofort die Probleme auf.
Die anderen Threads mit eigenen Filehandles sehen aber mit fread() die änderungen sofort.
Valar Morghulis
Gruss Carlo
Gruss Carlo
- Lewi
- 1000 working lines a day
- Beiträge: 830
- Registriert: Di, 07. Feb 2006 14:10
- Wohnort: Hamburg
- Danksagung erhalten: 2 Mal
Re: Low Level File I/O --> Interne Datenstrukturen zerstört
Das ist eben das Problem. Die geänderten Daten befinden sich ohne flcose() eben nicht auf dem Datenträger.
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2517
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: Low Level File I/O --> Interne Datenstrukturen zerstört
Ja aber das Problem dabei ist dass die XBase APP crasht, sobald ich jeweils nach dem Schreiben die Datei mit fclose() schliesse dann treten die Probleme auf, der crash kommt jeweils schon nach Sekunden ..... Sobald nicht nur geschrieben sondern auch gelesen wird.
Valar Morghulis
Gruss Carlo
Gruss Carlo
- Lewi
- 1000 working lines a day
- Beiträge: 830
- Registriert: Di, 07. Feb 2006 14:10
- Wohnort: Hamburg
- Danksagung erhalten: 2 Mal
Re: Low Level File I/O --> Interne Datenstrukturen zerstört
Kannst Du auschließen, das während eines Lesevorgangs gleichzeitig geschrieben wird? Meines Erachtens solltes Du dem Write-Thread nach dem Schreiben ein fClose() ausführen um die Daten physikalisch wegzuschreiben.
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2517
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: Low Level File I/O --> Interne Datenstrukturen zerstört
Nein, das kann ich nicht.
Valar Morghulis
Gruss Carlo
Gruss Carlo
- Lewi
- 1000 working lines a day
- Beiträge: 830
- Registriert: Di, 07. Feb 2006 14:10
- Wohnort: Hamburg
- Danksagung erhalten: 2 Mal
Re: Low Level File I/O --> Interne Datenstrukturen zerstört
Dann wirst Du wohl das Lesen einer Datei zum Zeitpunkt des Schreibens ( mit fclose() ) unterbinden müssen.
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2517
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: Low Level File I/O --> Interne Datenstrukturen zerstört
Nicht mal das geht!
Jetzt habe ich versucht die Datei Exclusive zu öffnen, so kann nur 1 Prozess mit der Datei was tun, die anderen müssen in einer "Sleep" Schlaufe bis zum fclose() des Vorgängers warten, das tun Sie auch, aber nicht mal das hilft.
Jetzt habe ich versucht die Datei Exclusive zu öffnen, so kann nur 1 Prozess mit der Datei was tun, die anderen müssen in einer "Sleep" Schlaufe bis zum fclose() des Vorgängers warten, das tun Sie auch, aber nicht mal das hilft.
Valar Morghulis
Gruss Carlo
Gruss Carlo
- Lewi
- 1000 working lines a day
- Beiträge: 830
- Registriert: Di, 07. Feb 2006 14:10
- Wohnort: Hamburg
- Danksagung erhalten: 2 Mal
Re: Low Level File I/O --> Interne Datenstrukturen zerstört
Was gibt den Flcose() an Bytes zurück? Deckt sich das mit den fWrite() geschrieben Bytes?
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2517
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: Low Level File I/O --> Interne Datenstrukturen zerstört
fClose() nur .t. zurück.
fWrite() gibt jeweils korrekte Werte zurück.
fWrite() gibt jeweils korrekte Werte zurück.
Valar Morghulis
Gruss Carlo
Gruss Carlo
- Marcus Herz
- 1000 working lines a day
- Beiträge: 852
- Registriert: Mo, 16. Jan 2006 8:13
- Wohnort: Allgäu
- Hat sich bedankt: 39 Mal
- Danksagung erhalten: 192 Mal
- Kontaktdaten:
Re: Low Level File I/O --> Interne Datenstrukturen zerstört
Ich hoff, du verwendest SYNC Methoden beim Schreiben , öffnen und lesen...
Das heisst, der Xbase Speicher ist kaputt, Speichervariablen zeigen auf einen flaschen/ungültigen Speicher. Evtl. in dem Fall alle nicht mehr benötigten Variablen explizit auf NIL setzen."Interne Datenstrukturen zerstört"
Gruß Marcus
Erkenne, was du findest, dann weißt du, wonach du gesucht hast
Erkenne, was du findest, dann weißt du, wonach du gesucht hast
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2517
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: Low Level File I/O --> Interne Datenstrukturen zerstört
Hallo Marcus
Ja, ich habe es auch mit einer Sync Methoden versucht. Keine änderung.
Das verrückte ist ja: Lasse ich den Handle des Schreibenden Threads offen funktioniert alles einwandfrei. Schreiben und Lesen. Über Tage.
***
Schliesse ich nach jedem Schreiben (alle 1-2 Sekunden) den fürs schreiben genutzten Handle funktionert das Schreiben in sich einwandfrei.
Dies solange keine lesenden Zugriffe kommen.
Kommen diese dazu, lesende Zugriffe (5-10 pro/Sek.) über fopen() --- fclose() krachts, meist schon nach Sekunden.
Ja, ich habe es auch mit einer Sync Methoden versucht. Keine änderung.
Das verrückte ist ja: Lasse ich den Handle des Schreibenden Threads offen funktioniert alles einwandfrei. Schreiben und Lesen. Über Tage.
***
Schliesse ich nach jedem Schreiben (alle 1-2 Sekunden) den fürs schreiben genutzten Handle funktionert das Schreiben in sich einwandfrei.
Dies solange keine lesenden Zugriffe kommen.
Kommen diese dazu, lesende Zugriffe (5-10 pro/Sek.) über fopen() --- fclose() krachts, meist schon nach Sekunden.
Valar Morghulis
Gruss Carlo
Gruss Carlo
- Jan
- Marvin
- Beiträge: 14655
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: Low Level File I/O --> Interne Datenstrukturen zerstört
Carlo,
kannst Du da ein Sample schreiben, mit dem das reproduzierbar so läuft? Dann mal an Alaska schicken.
Jan
kannst Du da ein Sample schreiben, mit dem das reproduzierbar so läuft? Dann mal an Alaska schicken.
Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- Marcus Herz
- 1000 working lines a day
- Beiträge: 852
- Registriert: Mo, 16. Jan 2006 8:13
- Wohnort: Allgäu
- Hat sich bedankt: 39 Mal
- Danksagung erhalten: 192 Mal
- Kontaktdaten:
Re: Low Level File I/O --> Interne Datenstrukturen zerstört
- man kann nicht ausschliessen, dass das ein Problem mit dem Windows Datei Cache ist. Aber mir fällt auch nichts ein, wie man das eingrenzen könnte
Gruß Marcus
Erkenne, was du findest, dann weißt du, wonach du gesucht hast
Erkenne, was du findest, dann weißt du, wonach du gesucht hast
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2517
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: Low Level File I/O --> Interne Datenstrukturen zerstört
Ach Jan
das habe ich doch auch schon versucht.
Ein kleines Testprogramm zu schreiben das den Fehler provoziert.
Leider gelingt mir dies nicht. Das kleine Testprogramm läuft mit einer kleinen Datei ohne SYNC oder weiteres absolut Problemlos.
Also muss es mit irgenwas, einer Einstellung oder Zusatz DLL wie L&L PDF-Tools oder sonstigem zusammenhängen das mithilt den Fehler zu erzeugen.
Nur mit was? Ich tappe völlig im Dunkeln.
das habe ich doch auch schon versucht.
Ein kleines Testprogramm zu schreiben das den Fehler provoziert.
Leider gelingt mir dies nicht. Das kleine Testprogramm läuft mit einer kleinen Datei ohne SYNC oder weiteres absolut Problemlos.
Also muss es mit irgenwas, einer Einstellung oder Zusatz DLL wie L&L PDF-Tools oder sonstigem zusammenhängen das mithilt den Fehler zu erzeugen.
Nur mit was? Ich tappe völlig im Dunkeln.
Valar Morghulis
Gruss Carlo
Gruss Carlo
- Marcus Herz
- 1000 working lines a day
- Beiträge: 852
- Registriert: Mo, 16. Jan 2006 8:13
- Wohnort: Allgäu
- Hat sich bedankt: 39 Mal
- Danksagung erhalten: 192 Mal
- Kontaktdaten:
Re: Low Level File I/O --> Interne Datenstrukturen zerstört
Da klingelts bei mir.Zusatz DLL wie L&L PDF-Tools
- Ich würde so vorgehen:
- es hängt wahrscheinlich gar nicht mit f-F<unktionen zusammen.
- Mach doch eine Kopie der Datei und lass die Lesevorgänge auf die Kopie los, dann kann man ausschliessen, dass es mit f Funktione zusammenhängt. Möcht drauf wetten, dass nicht.
- Datenstruktur korrupt: ich tippe auf die DLLs, die irgendwie in den Threads hängen bleiben. Hier hilft viuelleicht schon mal, alles auf NIL zu setzen, wenn der Thread geschlossen wird.
- Hier würde ich das mal ohne die AUfrufe der DLLs laufen lasen, auf der gleiche F Datei. Wahrscheinlich kommt dann kein Fehler.
- Welche der beiden DLLs jetzt der Verursacher ist, vielleicht kann man das mal nur mit der einne, dann der anderen laufen lassen, das Ergebnis muss ja nicht sinnvoll sein, es müssen nur die Module geladen werden, ein paar Aufrufe und Thread wiedder schiiessen.
Gruß Marcus
Erkenne, was du findest, dann weißt du, wonach du gesucht hast
Erkenne, was du findest, dann weißt du, wonach du gesucht hast
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2517
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: Low Level File I/O --> Interne Datenstrukturen zerstört
Hallo Marcus
danke für die Tips.
Ich denke auch dass es nicht die f-- Funktionen sind sondern eine kombination mehrere Punkte welche die f-- Funktionen stören.
Inzwischen habe ich auch noch direkt mit den File Funktionen aus der Kernel32 API versucht.
Der schreibende Thread und die zugehörigen Hilfs-Threads sowie auch alle darin enthaltenen Klassen und zusatz DLL's werden nie geschlossen alles läuft hier in Schlaufen und fragt mit den Zusatz DLL's über deren spezifische Kommunikations Protokolle über diverse verschiedene Schnittstellen die dazu gehörigen diversen Geräte ab und verteilt auch neue Werte. Das hat alles schon lange einwandfrei funktioniert ABER mit schreiben in eine DBF
Nun musste ich für eine Aufgabe was ändern und dachte zur Platz und Zeitoptimierung wäre ein Biräres File besser, war es auch, doppelt so schnell, halber Platz Verbrauch auf Platte, funktionierte auch ... solange der Schreibende Thread das File nicht schliesst.
Habe mich gestern Abend noch mit Kumpels getroffen und gequatscht, da meinte einer: Du bist ja immer der mit dem Spruch: Ändere kein laufendes System ... was tust du denn jetzt???
Nach längerem überlegen (ohne Wein) baue nun alles auf die vorherige, jahrelang bewährte, Variante mit dem Schreiben in die DBF zurück. Besser die Wochen Arbeit abschreiben als noch lange nach der Ursache zu suchen um dann rauszufinden dass es an der DLL XY liegt die speziell Entwickelt wurde und nicht so einfach zu ersetzten ist .........
Es ist zwar aus meiner Sicht unbefiedigend die Ursache nicht gefunden zu haben und zu kennen aber der Kunde bekommt sein Ding und ich darf aus dem Büro hinaus und für einige Zeit wieder auf die Strasse ...
danke für die Tips.
Ich denke auch dass es nicht die f-- Funktionen sind sondern eine kombination mehrere Punkte welche die f-- Funktionen stören.
Inzwischen habe ich auch noch direkt mit den File Funktionen aus der Kernel32 API versucht.
Der schreibende Thread und die zugehörigen Hilfs-Threads sowie auch alle darin enthaltenen Klassen und zusatz DLL's werden nie geschlossen alles läuft hier in Schlaufen und fragt mit den Zusatz DLL's über deren spezifische Kommunikations Protokolle über diverse verschiedene Schnittstellen die dazu gehörigen diversen Geräte ab und verteilt auch neue Werte. Das hat alles schon lange einwandfrei funktioniert ABER mit schreiben in eine DBF
Nun musste ich für eine Aufgabe was ändern und dachte zur Platz und Zeitoptimierung wäre ein Biräres File besser, war es auch, doppelt so schnell, halber Platz Verbrauch auf Platte, funktionierte auch ... solange der Schreibende Thread das File nicht schliesst.
Habe mich gestern Abend noch mit Kumpels getroffen und gequatscht, da meinte einer: Du bist ja immer der mit dem Spruch: Ändere kein laufendes System ... was tust du denn jetzt???
Nach längerem überlegen (ohne Wein) baue nun alles auf die vorherige, jahrelang bewährte, Variante mit dem Schreiben in die DBF zurück. Besser die Wochen Arbeit abschreiben als noch lange nach der Ursache zu suchen um dann rauszufinden dass es an der DLL XY liegt die speziell Entwickelt wurde und nicht so einfach zu ersetzten ist .........
Es ist zwar aus meiner Sicht unbefiedigend die Ursache nicht gefunden zu haben und zu kennen aber der Kunde bekommt sein Ding und ich darf aus dem Büro hinaus und für einige Zeit wieder auf die Strasse ...
Valar Morghulis
Gruss Carlo
Gruss Carlo
- Lewi
- 1000 working lines a day
- Beiträge: 830
- Registriert: Di, 07. Feb 2006 14:10
- Wohnort: Hamburg
- Danksagung erhalten: 2 Mal
Re: Low Level File I/O --> Interne Datenstrukturen zerstört
Hallo,
da ich die letzten Tage sehr “bussy“ war, möchte jetzt an dieser Stelle meine Sicht der Fehler-Ursache aufzeigen.
fwrite() schreibt die Daten nicht direkt auf die Festplatte sondern in einen vom OS verwalteten Prozess-Warteschlange. Es kann auch sein sein, dass xBase diesen internen Prozess-Buffer selbst verwaltet. Aber auch dann, hat letztendlich das xBase-Laufzeitsystem keinen Einfluss darauf, wann die Daten aus dem Puffer physikalisch auf dem Datenträger geschrieben werden. Der Write-Aufruf wird lediglich als Prozess initialisiert und in die Prozess-Warteschlange angehängt und irgendwann abgearbeitet.
Das File-Handle selbst hat wiederum ein eigenen System-Buffer.
fClose() als Low-Level Funktion schließt die Datei, veranlasst aber nicht das Schreiben . Es obliegt dem OS, wann die Daten geschrieben werden.
Die Datenschreibintegrität wird manchmal auch als Write through to disk on disk on flush bezeichnet. Dies kann mit fwite() und fclose() nicht sichergestellt werden. Erst wenn der Schreib-Prozess abgearbeitet worden ist, wenn alle system-internen Daten-Puffer gelöscht.
Auch wenn untermittelbar nach einem fclose() mit fOpen() und fread() auf die Datei lesend zugegriffen wird, könnte der write()-Befehl innerhalb der Prozess-Warteschlange noch nicht abgearbeitet worden sein. Eine Verzögerung der physikalischen Speicherung von Daten kann bei Windows und Linux beobachtet werden. Deutlich wird dies insbesondere bei USB-Laufwerken.
Hochsprachen wie C, Python oder PHP 8.1 stellen die Funktion fsync(nHandle) bereit. Die Funktion versucht, Änderungen auf den Datenträger zu übertragen. Anschließend werden alle internen Puffer geleert.
Ich denke, man hat bewusst den Sync-Befehl nicht im Zuge von fWrite() implementiert, weil es zu Lasten der Performance geht.
In PHP sieht das z.B. so aus:
Das irgendwelche ausgestiegenen DLL’s bei einem Thead als Ursache in Frage kommen, halte ich für unwahrscheinlich, wenn der Fehler ansonsten auch ohne Fremd-DLL’s reproduziert werden kann. Der Zugriff über fopen() und fread() führt zu Fehlermeldungen, weil sie wohl auf die internen Buffer zugreifen, diese aber noch mit alten Daten gefüllt sind. Diese Buffer werden in der Regel mit Zeiger-Arithmetriken verwaltet und führen dann in das Speicherstellen-Nirvana bzw. verweisen auf eine Speicherstelle, die nicht angelegt werden kann. Aber sind meinerseits nur Vermutungen.
Wenn ich mich recht erinnere, gibt es in xBase++ den fsync() -Befehl nicht. Dieser sollte m.E. von ALASKA dringend implementiert werden.
Da ich nicht mehr mit xbase++ programmiere, juckt mich allerdings dieser Umstand nicht.![😉](//cdn.jsdelivr.net/gh/twitter/twemoji@latest/assets/svg/1f609.svg)
da ich die letzten Tage sehr “bussy“ war, möchte jetzt an dieser Stelle meine Sicht der Fehler-Ursache aufzeigen.
fwrite() schreibt die Daten nicht direkt auf die Festplatte sondern in einen vom OS verwalteten Prozess-Warteschlange. Es kann auch sein sein, dass xBase diesen internen Prozess-Buffer selbst verwaltet. Aber auch dann, hat letztendlich das xBase-Laufzeitsystem keinen Einfluss darauf, wann die Daten aus dem Puffer physikalisch auf dem Datenträger geschrieben werden. Der Write-Aufruf wird lediglich als Prozess initialisiert und in die Prozess-Warteschlange angehängt und irgendwann abgearbeitet.
Das File-Handle selbst hat wiederum ein eigenen System-Buffer.
fClose() als Low-Level Funktion schließt die Datei, veranlasst aber nicht das Schreiben . Es obliegt dem OS, wann die Daten geschrieben werden.
Die Datenschreibintegrität wird manchmal auch als Write through to disk on disk on flush bezeichnet. Dies kann mit fwite() und fclose() nicht sichergestellt werden. Erst wenn der Schreib-Prozess abgearbeitet worden ist, wenn alle system-internen Daten-Puffer gelöscht.
Auch wenn untermittelbar nach einem fclose() mit fOpen() und fread() auf die Datei lesend zugegriffen wird, könnte der write()-Befehl innerhalb der Prozess-Warteschlange noch nicht abgearbeitet worden sein. Eine Verzögerung der physikalischen Speicherung von Daten kann bei Windows und Linux beobachtet werden. Deutlich wird dies insbesondere bei USB-Laufwerken.
Hochsprachen wie C, Python oder PHP 8.1 stellen die Funktion fsync(nHandle) bereit. Die Funktion versucht, Änderungen auf den Datenträger zu übertragen. Anschließend werden alle internen Puffer geleert.
Ich denke, man hat bewusst den Sync-Befehl nicht im Zuge von fWrite() implementiert, weil es zu Lasten der Performance geht.
In PHP sieht das z.B. so aus:
Code: Alles auswählen
function writeInTestFile() {
$success = false;
$file = fopen('test.txt', 'wb');
$data = "Hello\nthis is a test!";
if (fwrite($file, $data) !== false) {
$success = fsync($file);
}
fclose($file);
return $success;
}
Wenn ich mich recht erinnere, gibt es in xBase++ den fsync() -Befehl nicht. Dieser sollte m.E. von ALASKA dringend implementiert werden.
Da ich nicht mehr mit xbase++ programmiere, juckt mich allerdings dieser Umstand nicht.
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2826
- Registriert: Fr, 08. Feb 2008 21:29
- Hat sich bedankt: 96 Mal
- Danksagung erhalten: 13 Mal
Re: Low Level File I/O --> Interne Datenstrukturen zerstört
Hallo, Lewi -
interessante Darstellung, danke!
Unter Windows gibt es den Befehl fflush (https://docs.microsoft.com/de-de/cpp/c- ... w=msvc-170), den man eigentlich recht einfach abbilden könnte, und der anscheinend mit dem gleichen Dateihandle arbeitet, das auch in Xbase++ zur Verfügung steht.
interessante Darstellung, danke!
Unter Windows gibt es den Befehl fflush (https://docs.microsoft.com/de-de/cpp/c- ... w=msvc-170), den man eigentlich recht einfach abbilden könnte, und der anscheinend mit dem gleichen Dateihandle arbeitet, das auch in Xbase++ zur Verfügung steht.
Liebe Grüsse aus der Eifel,
Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
- Herbert
- Der Entwickler von "Deep Thought"
- Beiträge: 1991
- Registriert: Do, 14. Aug 2008 0:22
- Wohnort: Gmunden am Traunsee, Österreich
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
Re: Low Level File I/O --> Interne Datenstrukturen zerstört
Abgeleiteet aus dieser interessanten Darstellung fragt sich, warum im gegebenen Beispiel mit Dateien gearbeitet wird.
Falls der Dateiinhalt nicht enorm ist und der Inhalt fassbar ist, dann könnte besser der gesamte Inhalt in eine SQL-TAbelle gelegt werden. Dadurch wäre das korrekte Zugreifen gewährleistet.
Falls der Dateiinhalt nicht enorm ist und der Inhalt fassbar ist, dann könnte besser der gesamte Inhalt in eine SQL-TAbelle gelegt werden. Dadurch wäre das korrekte Zugreifen gewährleistet.
Grüsse Herbert
Immer in Bewegung...
Immer in Bewegung...
- mikehoffmann
- Rekursionen-Architekt
- Beiträge: 133
- Registriert: Mo, 21. Sep 2015 16:22
- Hat sich bedankt: 1 Mal
- Danksagung erhalten: 18 Mal
Re: Low Level File I/O --> Interne Datenstrukturen zerstört
Hallo Ramses,
ich glaube nicht, dass das Problem im Xbase zu suchen ist. Die F-Funktionen werden bestimmt direkt weiterrufen in die API-Funktionen und auch gleich das Ergebnis abliefern. Ich selber verwende die Dinger normalerweise nicht, weil man da so gut wie nix angeben kann, was man selber gerne machen würde und was man anderen Dateizugreifern gestatten möchte. Und asynchroner I/O ist auch nicht möglich. Ich nutze daher die API-Funkionen und das funktioniert eimandfrei, wie man in Franken sagt.
Allerdings ist auch nicht auszuschließen, dass die Xbase-Funktionen doch nicht ganz astrein sind. Auch bei den Zugriffen auf die Debe-Äffchen und Ente-Ixen fängt Xbase nicht alle Dramen sauber ab, was tatsächlich zum plötzlichen Kindstot führt.
Wenn Du ein Progrämmsche schreibst, das den Fehler reproduziert, dann hole ich die Abgreifklemmen (DllCall-Hooks) raus und wir schauen nach, was im Souterrain passiert.
Viele Grüße
Michael
ich glaube nicht, dass das Problem im Xbase zu suchen ist. Die F-Funktionen werden bestimmt direkt weiterrufen in die API-Funktionen und auch gleich das Ergebnis abliefern. Ich selber verwende die Dinger normalerweise nicht, weil man da so gut wie nix angeben kann, was man selber gerne machen würde und was man anderen Dateizugreifern gestatten möchte. Und asynchroner I/O ist auch nicht möglich. Ich nutze daher die API-Funkionen und das funktioniert eimandfrei, wie man in Franken sagt.
Allerdings ist auch nicht auszuschließen, dass die Xbase-Funktionen doch nicht ganz astrein sind. Auch bei den Zugriffen auf die Debe-Äffchen und Ente-Ixen fängt Xbase nicht alle Dramen sauber ab, was tatsächlich zum plötzlichen Kindstot führt.
Wenn Du ein Progrämmsche schreibst, das den Fehler reproduziert, dann hole ich die Abgreifklemmen (DllCall-Hooks) raus und wir schauen nach, was im Souterrain passiert.
Viele Grüße
Michael