Suche Buffered-File Klasse

hustbaer

klein kind schrieb:

könnt man ned die crt hacken???????

Klar.
Man könnte sich auch ein Loch ins Knie schiessen, und dann raustrinken.

theta

10k Limit: http://support.microsoft.com/kb/327699
Scheint aber variabel zu sein.
Simon

Tachyon

hustbaer schrieb:

Hm. Wo gibt's da ein 10k Limit? Ich hab ohne irgendwelche Tricks 60k offene Files hinbekommen...

Das habe ich selbst nur aus einem Forum.
Kann also gut Blödsinn sein. Wie im EIngangspost geschrieben, habe ich nur bedingt Ahnung, und hab mich nur aus Interesse etwas (halb) schlau gemacht.

hustbaer schrieb:

Hier müsste ich dann basic_streambuf implementieren, oder wie? Leider hab' ich von der ganzen iostream Geschichte kaum eine Ahnung[...]

Ich gucke morgen noch einmal nach. Vielleicht kann auch einer der Stream-Spezis was Genaueres aus dem Stegreif sagen (Werner?).

theta schrieb:

10k Limit: http://support.microsoft.com/kb/327699
Scheint aber variabel zu sein.
Simon

scheint sich nur auf user32.dll zu beziehen.

hustbaer

So.

Hab mir mal die Boost.Iostreams ganz kurz angeguckt. Sieht so aus, als ob da alles drin wäre was ich brauche (und mehr).
boost::iostreams::stream<boost::iostreams::file_descriptor> sieht auf den ersten Blick mal genau nach dem aus, was ich gesucht habe.
Fix & fertig, out-of-the-box gepufferte IO Klasse, auf Basis von OS-Handles!

Ich werde berichten wie das Ding sich macht. Speziell was Memory-Overhead angeht. Performance werd ich erstmal nicht gröber testen -- solange es deutlich schneller als direkte OS-Calls ist, wird es für meine Zwecke reichen.

Badestrand

Aus Spaß an der Sache hab ich da mal was gebastelt: *klick*. Wie eine streambuf-Lösung aussieht, würde mich aber auch interessieren.

Interface von dem Ding sieht so aus:

class BufferedFile
{
	public:
		explicit BufferedFile( const std::string& filename, std::ios_base::openmode open_mode );
		~BufferedFile();

		void seek( long long offs, std::ios_base::seek_dir dir=std::ios::beg );

		size_t read( void* buffer, size_t to_read );
		size_t readAt( void* buffer, size_t to_read, long long offs, std::ios_base::seek_dir dir=std::ios::beg );

		size_t write( const void* buffer, size_t to_write );
		size_t writeAt( void* buffer, size_t to_write, long long offs, std::ios_base::seek_dir dir=std::ios_base::beg );

		unsigned long long tell() const;
		unsigned long long size() const;
};

edit: Mist...

edit2: Link nochmal rausgenommen, war zu Testzwecken was gefährliches drin, korrigiere morgen

edit3: Ist wieder da und in Ordnung gebracht.

hustbaer

@Badestrand:
Das ist nur die halbe Miete, denn Writes werden garnicht gepuffert

Badestrand

hustbaer schrieb:

@Badestrand:
Das ist nur die halbe Miete, denn Writes werden garnicht gepuffert

Argh, natürlich! Bin bis jetzt mit gepufferten Writes quasi nie direkt in Kontakt gekommen, da hab ich's einfach vergessen.. Gut. Hm, nagut, hab ich halt ein wenig rumgespielt. Übrigens hab ich auch generell keine Ahnung von Buffering/Caching. Ich weiß, du willst es nur anwenden, aber hast du eventuell Links zu Artikeln? Ist an sich ja ein interessantes Feld.

hustbaer schrieb:

Nur im Kernel-Mode, über den normalen File-Cache.
100.000x ReadFile mit einem Byte ist allerdings *VIEL* langsamer, als wenn im User-Mode nochmal ein (kleiner) Buffer verwendet wird.
...
jeder einzige ReadFile Befehl führt dazu dass eine User-Mode -> Kernel-Mode Transition stattfindet, ein neuer IRP erstellt wird, der IRP an den zuständigen Treiber übergeben wird, dann irgendwann "bedient", dann wieder freigegeben, dann wieder eine Kernel-Mode -> User-Mode Transition, und dann irgendwann, 100 Jahre später, kommt ReadFile zurück.
...

Mich würde interessieren wo du diese detailierten Informationen her hast. Konnte es zwar auch relativ schnell nachschlagen und deine Angaben bestätigen, aber mich würde interessieren ob du dieselbe Quelle verwendest. In den gängigen Büchern zur Win32-API (Petzold, Richter, Hart) steht es jedenfalls nicht.

hustbaer

Ich habe schon zwei Treiber für Windows 2000/XP geschrieben, und musste mich daher etwas mit der Materie auseinandersetzen. Waren zwar beides keine File-System Treiber, aber mein Verständnis reicht soweit, um zu wissen, dass die grundlegenden Mechanismen die selben sind. Die Informationen hab' ich zum Teil aus der DDK Dokumentation, der Compuware DriverWorks Dokumentation, und zum Teil von äusserst hilfreichen Leuten über die "ntdev" Mailing-List von OSR Online (http://www.osronline.com/).

Klar, ich Trottel, Treiberentwicklung. In der entsprechenden Literatur finden sich dann auch die Informationen. Daran hab ich nicht gedacht. Danke für den Hinweis.

hustbaer

Nachfrager schrieb:

Klar, ich Trottel,

Wieso Trottel
War doch ne ganz normale Frage...
(Und ne ganz normale Antwort)

Nein, ich hab mich nur geärgert, weil der Groschen bei mir so spät (erst nachdem ich nachgefragt hatte) gefallen ist.

Ich stand nämlich nach deinem Beitrag vor meinem Regal und dachte: Wenn ich das jetzt genau wissen will, wo würde ich nachschlagen? Dann habe ich kurz 3 Bücher zur Win32 API durchgeblättert bevor mein Auge auf das Buch von Russinovich & Solomon fiel. Darin wird es zwar erklärt, aber das ist ja eigentlich kein typisches Buch für Programmierer.

Und "Trottel" deswegen, weil ich nicht selbst darauf gekommen bin mal im Buch von Walter Oney nachzuschlagen, wo es ja wirklich groß und breit behandelt wird. Erst als ich in deinem Beitrag das Wort "Treiber" las, hat es bei mir klick gemacht, gefolgt von einem leichten Schlag mit der flachen Hand gegen die Stirn.

Manchmal verliert man in dem Informationsdschungel den Überblick ...

hustbaer

OK. Du darfst dich natürlich selbst nennen wie du magst
Ich fand die Frage auf jeden Fall nicht dumm/unberechtigt/... .