Ke IO traits - umí některý z nich random access read/write ala pread() / pwrite() ?
Nedávno jsem na to narazil v Java, kde je to udělané megablbě a tyhle operace podporuje jenom FileChannel, zatímco pro seek je třeba SeekableByteChannel interface. Takže virtuální implementace channel s random access je prakticky nemožná.
Tak jen ze zvědavosti, jestli se z toho autoři Rust poučili :-)
Asi nejbližší je k tomu:
https://doc.rust-lang.org/std/fs/struct.File.html#method.read_at
https://doc.rust-lang.org/std/fs/struct.File.html#method.write_at
Ten trait se jmenuje std::os::unix::fs::FileExt a sám mám všude "jen" Linux :-) takže teď nedokážu otestovat, jak a jestli vůbec to funguje na ostatních systémech.
DESCRIPTION .... The file offset is not changed. ...
NOTES
The pread() and pwrite() system calls are especially useful in multithreaded applications. They allow multiple threads to perform I/O on the same file descriptor without being affected by changes to the file offset by other threads.
Ano, dalo by se říci i tou atomicitou (jako by), ale hlavně že file offset (seek) zůstává nedotčen, takže seek může být využit např. v hlavním threadu (a všechny operace jej využívající), kdežto ostatní thready mohou přímo via pread. A nekacají si do toho.
Spíš bych řekl, že seek() se pak nepoužívá vůbec.
Typicky je to asi v databázích, ale obecně cokoliv, co potenciálně vyžaduje concurrent přístup. Nedávno jsem řešil třeba v Apache commons-compress, se seek() byl výkon s bídou na 10% : COMPRESS-388.
Jasné.
To jsem myslel pro případ, že ve vlastní knihovně potřebuji samostatný přístup, ale netuším, kdo si kdy, za jakých podmínek, bude knihovnu nakonec linkovat. Tak vím, že s pread nikomu nic neponičím (ani v multithread prostředí) a nemusím na to upozorňovat.
Rychlostní výhody při intenzivnějším čistě paralelním přístupu jsou, jak je vidět, další výhoda. Dobré vědět. Je to nasnadě.