Načítání dat v C: read vs. fread (diskuse)

[move On]

Jako cool, ze se tady resi programatrostina, ale neni C tak 20 let za zenitem a opicema? Co takhle Rust?

[johnyK]

ja pisu v kazdem jazyku C-programy

[dik]

První příspěvek a hned rust-katolík Víš jak poznáš že někdo dělá v rUsTU? řekne ti to.

[move On]

Co to jsou za konzervativni kecy? Je Cecko 50leta vykopavka? Je. Ma sve fatalni mouchy? Ma. Tak proc nepodporit jazyk, ktery je ve vsem lepsi nez C a syntakticky velice blizky?

[dik]

Kliiiid vegane, věř si čemu chceš ale nikomu to necpi.

[plostenka]

Uz ma Rust dynamicky linkovane knihovny? Uz je v ABI kompatibilni aspon zpetne sam se sebou?

[move On]

Samozrejme ze binarni interfejs je v Rust spetne linkovatelny. Ceckare ale sere ze neni kompatibilni a nemohou tak krast krasne knihovny napsane v Rustu! Detto dynlink, prekonany koncept z dob kdy se setrilo harddiskem. Proc ma kazdy flatpack apky? Aby se predeslo dll hell s dynamickymi knihovnamy Sherlocku. Takze se tu nesnaz prudit ceckarskyma starozitnostma kdyz jsou mimo misu.

[kralyk z abclinuxu]

Uz ma Rust dynamicky linkovane knihovny? Uz je v ABI kompatibilni aspon zpetne sam se sebou?

ABI stabilní není.

Dynamické linkování funguje už velmi dlouho, akorát ti s tim nepomůže tooling a musíš si sestavování, kompatibilitu etc. řešit do značný míry sám. Osobně bych nečekal, že by vůbec někdy Rust v nějaký větší míře přecházel na dynamické linkování vzhledem k širokému používání generik. Dynamického linkování v Rustu bych spíš viděl jako doplněk pro případy jako třeba nějaké binární pluginy apod.

[xkucf03]

Syntakticky blízké je třeba D nebo Java. Zrovna Rust je dost jiný (a často mi přijde, že poněkud samoúčelně, podobně jako Go… trochu z toho čiší snaha dělat věci za každou cenu jinak a vymezovat se proti stávajícím jazykům).

[kralyk z abclinuxu]

První příspěvek a hned rust-katolík Víš jak poznáš že někdo dělá v rUsTU? řekne ti to.

Spíš je to troll, kterýmu je to reálně jedno, jen si našel způsob trollení.

[NUKE GAZA! 🎆]

aje teda jakoby víc lepšejší rust nebo c????? :O :O ;D ;D

[Gilhad]

To jako záleží na tom, koho zrovna chceš vícejc trolit :D :D :D

[move On]

Rustaka nevytrolis, ma IQ i EQ. Na fakta ti odpovi anekdotou a na emoce te zazdi neprustrelnym faktem. Takze prudit tu budou hlavne C-konzervy s bibli od Kernighan-Richieho v ruce jedne a s "Jak poznam srakzmus" v ruce druhe.

[kralyk z abclinuxu]

aje teda jakoby víc lepšejší rust nebo c????? :O :O ;D ;D

No, tak čistě osobně jsem rustem nadšen od doby, co jsem s tim začal něco dělat (ca. 2014), takže samozřejmě rust :Đ, ale to je subjektivní, objektivní názor neexistuje a záleží, jaký máš požadavky, preference a tak...

[Tomáš Roll]

Nejlepší je Java - píšeš podobnou syntaxí jako v céčku, ale je to mnohem bezpečnější. Plus tam máš generika i sdílené knihovny (nemusíš si vybrat jen jedno z toho, jak by ti nutil Králík).

[Tro7]

A elf binarka hello worldu v jave ma 5 mega nebo 6 ?

[kralyk z abclinuxu]

Nevim jak v Javě, ale v Rustu zhruba tolik no

[Debian-]

To jsou pomluvy! HelloWorld v C 8k, v Rust 400k.

[kralyk z abclinuxu]

By default dostanu z release buildu u mě 3.2MB. Je ale pravda, že naprostá většina toho jsou debug symboly, který když stripnu, je z toho ~300k...

[linker]

Tych 8k je len preto, lebo to nemas staticky zlinkovane so stdio, teda libc, co na linuxe je glibc a bude to mat 2 mega kamo.

[Tomáš Roll]

Má to nějakých 2,4 MB (zkoušeno se starší verzní GraalVM). Ano, na hello world, který jen na výstup vyplivne pár bajtů, je to hodně, ale nezávisí to na žádných dynamických knihovnách (kromě obligátních systémových libc, librt, linux-vdso...) a když si vypíšeš symboly (nm), tak zjistíš, že to podporuje Unicode a konverzi kódování UTF-8, UTF-16, ISO-8859-1, ASCII... nebo že tam máš garbage collector a další věci. Jasně, můžeš říct, že pro hello world to je zbytečné a navíc, ale v drtivé většině aplikací zrovna tyhle věci potřebuješ a do té céčkovské aplikace by sis příslušné knihovny musel přidat a ta binárka by ti taky nakynula. Výsledek je pak srovnatelný, akorát v té Javě se píše o dost pohodlněji a máš tam lepší správu paměti, tu podporu Unicodu a další věci, které moderní vysokoúrovňový jazyk podporuje.

Jinak ano, taky je mi bližší, když si člověk explicitně přibalí jen to, co potřebuje, a ta základní povinná výbava je minimální. Ale těch 2,4 MB je na dnešní poměry docela málo a zbytečností tam moc není. Takže za mě je tohle fajn cesta. Určitě lepší než smolit nějaké céčko jak v 70. letech a každou chvíli se střílet do nohy.

[j]

Spis tak 500 ... nezapomen zahrnout jeste vsechny ty sracky kolem ktery potrebujes k tomu aby to slo vubec spustit.

---

Dete s tim guuglem dopice!

[gugl nepujde do pice]

Bavime se o prekompilovane elf binarce, ne o java runtime ktera samozrejme potrebuje podporne soubory JRE.

[katon]

Však Ti nikdo nebrání něco o RUSTu napsat, o čem píšou ostatní je jejich věc..

[johnyK]

Z hlediska uživatele (programátora uživatelské aplikace) je důležité třeba to, že read a write můžou vrátit jenom částečně naplněný buffer (jako návratovou hodnotu vrátí, kolik dat se skutečně přečetlo/zapsalo, a pokud chcete víc, tak je musíte spustit znova se zbytkem dat)

to je skutecne u site nebou roury ten pripad, jak pises, ale u souboru na harrdisku si myslim je mozne rici, ze pokud se neprecte tolik, kolik se zadalo v tom odpovidajicim parametru, tak je problem ...

[Jendа]

Ještě mohl přijít signál (třeba u dd je tohle populární, protože mu lidi posílají USR1 aby se dozvěděli progress).

[plostenka]

dd uz nejakou dobu umi status=progress.

[Josef Kufner]

Nebo je fragmentovaný soubor a než se našel druhý blok, tak přišel signál a volání přerušil.

[johnyK]

ale u toho signalu je pak return-code = -1 nebo?

jediny co u harddisku snad muze byt, kdy je return >= 0 , kdyz se aktualni pozice v souboru nachazi nekde u konce toho souboru a je pozadovano vice bajtu jak jeste do konce zbyva. Pak se skutecne vrati min nez pozadovano a pro to pristi volani (kdy chci ten 'mysleny' zbytek) se vrati nula - coz je take samozrejme spravne.

Ale takovy vyse uvedeny pripad je podle me jen teorie, ktera nema s aplikacni praxi nic moc spolecneho. Jestlize v aplikaci ocekavam nejaky pocet bajtu a nedostanu je, tak je asi nekde chyba.

[Josef Kufner]

Pokud se systémové volání přeruší dřív (např. signálem), než načte všechna požadovaná data, tak jich prostě vrátí méně. Ten read() je vážně nízkouúrovňová věc, která toho moc neumí. Proto máme fread(), který takové ošklivosti řeší a drží si vlastní buffer, který se do integeru (file descriptoru) prostě nevejde (narozdíl od FILE*).

[Michal Kubeček]

Konkrétně viz read(3p):

If a read() is interrupted by a signal before it reads any data, it shall return −1 with errno set to [EINTR].

If a read() is interrupted by a signal after it has successfully read some data, it shall return the number of bytes read.

[johnyK]

diky za odpoved, ale presto bych rad, aby to nekdo ted vysvetlil.

Ja se priznam, ze prichazim z jine doby a za me existoval jen read(2). - to jsem ted zkontroloval v me referencni prirucce od AT&T pro unix system V. Take tam stoji, ze kdyz se behem toho volani read vyskytne signal, tak je return = -1. O tom jestli se neco precetlo nebo ne se tam nic nerika.

Dost jsem koukal, ze to co jste uvedl skutecne existuje = read(3p).

K tomu mam ted samozrejme otazku - v tech linux manual pages pro read(2) a read(3p) jsem nepostrehl, jak to udelam aby se vyvolala ta funkce=(3p) a nebo ten syscall=(2).

Autor blogpostu rozlisoval prave read a fread -> tam je to jasne co je syscall a co je knihovni funkce.

Jeste na okraj, u toho read(2) mam pocit, ze i v tech novych manual pages se u signalu vrati -1 at uz se neco nacetlo nebo ne.

[Michal Kubeček]

read(3p) je posixová manuálová stránka, která popisuje, jak by se ten syscall měl chovat podle POSIXu. read(2) je linuxová manuálová stránka, která (je-li dostatečně aktuální) popisuje, jak se aktuálně chová na Linuxu (včetně případných rozšíření).

[Michal Kubeček]

Jinak moje verze read(2) také uvádí

EINTR     The call was interrupted by a signal before any data was read; see signal(7).

Dává to tak i víc smyslu. Pokud byste vrátil -1/EINTR, nebude mít volající šanci poznat, jestli se něco přečetlo a pokud ano, kolik toho bylo.

[Michal Kubeček]

u souboru na harrdisku si myslim je mozne rici, ze pokud se neprecte tolik, kolik se zadalo v tom odpovidajicim parametru, tak je problem

Ne tak úplně:

mike@lion:/srv/ram> ls -l file8
-rw-r--r-- 1 mike users 8589934592 zář  5 01:12 file8
mike@lion:/srv/ram> strace dd if=file8 of=/dev/null bs=8G 
...
read(0, "t\371\246\323\310\34\365\332\202\200'X\366\234GI\327N9\353\224\361\n\315\200)z(?\221\220&"..., 8589934592) = 2147479552
write(1, "t\371\246\323\310\34\365\332\202\200'X\366\234GI\327N9\353\224\361\n\315\200)z(?\221\220&"..., 2147479552) = 2147479552
read(0, "\234]Z\213\217\214B\247 SZ\320\20\361\273i\376\250?\26\324\320\333\213\n\256^=\26{0\325"..., 8589934592) = 2147479552
write(1, "\234]Z\213\217\214B\247 SZ\320\20\361\273i\376\250?\26\324\320\333\213\n\256^=\26{0\325"..., 2147479552) = 2147479552
read(0, "\"\177l\254\316\212\325\342]\378\244;*\\\365l\25A\352\6\t\310\311/\313\336.\23\250D<"..., 8589934592) = 2147479552
write(1, "\"\177l\254\316\212\325\342]\378\244;*\\\365l\25A\352\6\t\310\311/\313\336.\23\250D<"..., 2147479552) = 2147479552
read(0, "\204\232\271\5\225\10/J\346\333\236\326/~{\264\214\217\244\31\367\212SK\220\2421\220\302n<A"..., 8589934592) = 2147479552
write(1, "\204\232\271\5\225\10/J\346\333\236\326/~{\264\214\217\244\31\367\212SK\220\2421\220\302n<A"..., 2147479552) = 2147479552
read(0, "\372\271\247_\252K\32\253\253\372\366\300\34\37\362\33\332\363\r{\3\6-\24\20\344\302\376\333~\366\245"..., 8589934592) = 16384
write(1, "\372\271\247_\252K\32\253\253\372\366\300\34\37\362\33\332\363\r{\3\6-\24\20\344\302\376\333~\366\245"..., 16384) = 16384
read(0, "", 8589934592)                 = 0
close(0)                                = 0
close(1)                                = 0
...
0+5 records out
8589934592 bytes (8,6 GB, 8,0 GiB) copied, 1,06331 s, 8,1 GB/s)

[Josef Kufner]

Hlavní rozdíl mezi read() a fread() je v tom, že read() je dost těžké použít zcela správně. Takže hlavní poučení je používat knihovny, například fread(), kde už se s tím trápil někdo jiný.

[Michal Kubeček]

Většinou ano, ale jsou situace, kdy je potřeba jemnější kontrola nad tím, co a jak se přesně čte nebo zapisuje, kterou ta knihovní nadstavba neumožňuje.

[luky]

Tak treba pri cteni virtualnich souboru (/proc/, /sys/ etc.) muze fread nacist bordel, protoze neprecte data jednim volanim, a je mnohem vetsi sance, ze uzivatel dostane, co ceka, pokud pouzije read. Jedine, co jde doporucit, je, at se programator seznami s tim, jak funguje I/O na urovni jadra a jak funguje "nadstavba" v glibc a potom si vybere podle potreby.

[z_sk]

Tak subor z /proc treba citat po bajtoch. Zrejme to je znakove pseudo-zariadenie, a nie blokove.

[kvr]

To vůbec nesouvisí s tím, zda je blokové nebo znakové a vůbec nesouvisí s tím, jestli fread vs read přečtou celé nebo jenom kus. Bude-li čtení přerušeno, tak fread se taky může vrátit předčasně (teď nevím, co přesně udělá EINTR či EAGAIN, ale všechny ostatních chyby se budou reportovat). /proc jsou typicky virtuální soubory (případně část pseudo-linky na skutečné soubory), kernel bude mnohem radši, když jej userspace přečte celý najednou než po bytech.

[Michal Kubeček]

Jádro se s tím nějak vypořádá, problém je spíš v tom, že mnohé soubory v proc nebo sysfs prezentují aktuální stav, který se průběžně mění, takže je docela dobře možné, že složením toho, co přečtou dvě volání read(), dostanete nekonzistentní obsah (a dost možná i obsah, který vůbec nedává smysl).

[kvr]

Já bych řekl, že výsledky budou atomické. Což znamená, že jádro si musí někde zapamatovat aktuální stav v době prvního čtení (případně ten zformátovaný buffer). Takže ano, jádro se s tím samozřejmě vypořádá, ale bude stát tenhle snapshot navíc, proto věta "jádro bude určitě radši, když si userspace přečte všechno najednou".

[Michal Kubeček]

Aby tohle mohlo fungovat, muselo by jádro držet buď celý snapshot v podobě, v jaké půjde na výstup, nebo data, ze kterých se generuje. Jednak vím, že to tak není, protože už jsem s generováním proc souborů měl něco do činění, jednak to tak dost dobře fungovat ani nemůže, protože mezi těmi dvěma voláními může uběhnout libovolně dlouhá doba nebo dokonce druhý read() nemusí přijít vůbec a pak byste tam měl leak za každé takové nedokončené čtení.

[xkucf03]

Nebylo by pak lepší napoprvé vracet chybu, pokud se nepovede načíst vše najednou?

Třeba informace z alsy jsou někdy docela dlouhé:

$ cat /proc/asound/card0/codec#0 | wc 
    113     527    3958

Jindy je to třeba jen jedno číslo nebo jeden krátký řádek.

[Michal Kubeček]

Nebylo by pak lepší napoprvé vracet chybu, pokud se nepovede načíst vše najednou?

Někde by to asi smysl mělo, ale určitě ne obecně. Co když userspace opravdu zajímá jen začátek? Navíc existují soubory jako /proc/kcore, které celé najednou ani přečíst nejdou.

Mimochodem, 3958 není tak moc, to se pořád vejde do 4096, což je IIRC defautní délka bloku, po kterém čte glibc, pokud si neřeknete o víc (např. když zavoláte fgetc()). Ale jsou i soubory, které mohou být podstatně delší, např. v /proc/net.

[xkucf03]

To je pravda, někdo asi může chtít číst jen začátek a nemusí to být chyba. Správné řešení by nejspíš bylo to vázat na otevřený FD a dokud ho uživatel nezavře, tak držet tu původní verzi konzistentní (zatímco jiným už poskytovat novější data). Akorát by se musela paměť alokovat dynamicky a bylo by to náročnější na implementaci.

[luky]

Todle je blbost z nekolika duvodu:

- Muzete si otevrit soubor a cist ho treba kazdou vterinu, a tim samplovat stav systemu. Periodicke volani pread s offsetem 0 na fd souboru v /proc nebo /sys je beznej usecase.

- U velkych souboru by to slo pouzit k DOS, protoze bych mohl vyalokovat mnohem vic pameti, nez mi povoluje ulimit (pamet by slo omezit jen pomoci memcg).

- Mrhani zdroji pri generovani dat, ktera nikdo necte.

Nejlepsi proste je, kdyz uzivatel neni pitomec a preste si, jak veci funguji, nez je pouzije. Pak se muze informovane rozhodnout, jestli data potrebuje precist atomicky a nebo ne a podle toho proste pouzije velkej buffer a nebo ne.

[Jendа]

Mimochodem nedávno se řešil readfile syscall, který načte soubor a tečka - takže věci co čtou periodicky hodně z /proc nemusí dělat open, (p)read, close. Ale zatím to nevypadá hotově.

[luky]

Tak to nemusej ani ted, muzou volat v cyklu pread Hodi se to spis pro aplikace typu grep, co prohledava vsechny soubory.

[kralyk z abclinuxu]

Hodi se to spis pro aplikace typu grep, co prohledava vsechny soubory.

AFAIK rychlý alternativy ke grepu (ag, ripgrep) se na tohle snažej používat memory mapping. ripgrep v komentářích tvrdí, že používá heuristiky, ale jestli to dobře čtu, tak jen vypne mmaping na 32 bitech a na macosu, ale jinak se snaží používat mmap.

Nevim, jestli readfile má tohle změnit...

[Jendа]

To se vyplatí pro velké soubory. Pokud máš malinké soubory, bude mít mmap taky overhead (otevřít a zavřít ten soubor musíš stejně, takže zbytečně mnoho syscallů se děje, a ještě asi budeš muset udělat munmap).

[kralyk z abclinuxu]

Zmíněný nástroje by default používaj mmap pro všechny velikosti. Můj odhad je, že pro velký soubory to je rychlejší a pro malý to vyjde nastejno...

[kralyk z abclinuxu]

Když jsem si tady hrál s těmi kernel ultras fortunami v kernelu, dělal jsem to tak, že jsem sestavil ten obsah v paměti a pak ho vrátil do userspace celej, takže na jedno volání (typicky to bylo pár stovek bajtů, možná kilobajt). Pokud měl userspace menší buffer než výsledek, tak jsem mu řekl, že EINVAL. (Což možná není úplně košér / serióznější projekt by to asi udělal jinak, ale zas mi nepřijde, že možností by bylo kdovíkolik, protože jak píšeš, člověk si tam nechce skladovat někde nějaký rozdělaný "transakce".)

[z_sk]

Nemáš pravdu o glib knižnice. Ona je doplnok, nie náhrada. Napr. glib nemá niečo také, ako je fclose. :) Napr. má user-like hast tables.

[johnyK]

autor napsal glibc

[z_sk]

Tak funkcie s prefixom majú aj vážny dôvod. Sú aj user like. Ošetrujú kadejaké vynimky, trebárs chyba na busy. A jasne, nastavovanie/rušenie týchto prípadných signálov niečo výkonu stoji.

[kvr]

fread žádné signály nenastavuje. Implementuje userspace cache, aby se pro každý byte nešlo do jádra a organizuje čtení do bloků, které vyžaduje volající. To má klady a zápory, jak s ohledem na výkon, tak některé potenciálně nechtěné vedlejší efekty, jako nekonzistence mezi tím, co říká jádro a co říká userspace (například select vrací žádná data, zatímco v userspace buffer ještě jsou).

[Michal Kubeček]

Zrovna použití select() / poll() / epoll() je příklad toho, kdy je potřeba jít na nižší úroveň a knihovní nadstavby použít nejde. Vlastně už samotné neblokující čtení by se s fread() kombinovalo dost obtížně.

[Josef Kufner]

To není pravda. Filedescriptor můžeš získat pomocí fileno() a vesele ho předat select(). Například Qt toto umí také. Také jde naopak někde sebrat file descriptor a pomocí fdopen() si nad ním nachystat tu nadstavbu.

Neblokující IO je však trochu jiná kapitola, tam už to je komplikovanější.

[Michal Kubeček]

fileno() nebo fdopen() je ta jednoduchá část. Problém je v tom, že otázka, jestli read() bude blokovat, není stejná jako jestli fread() bude blokovat. A kterýkoli z těch tří syscallů mi odpoví jen na tu první, zatímco mne, pokud budu používat ke čtení fread() bude zajímat ta druhá.

[NUKE GAZA! 🎆]

supr fígl to ulocked dělání se souboramama :O :O snad stim jako někde neudělám neštěstí :D

[Martin Mareš]

Jendo, neměl bys chuť změřit i bufferované I/O z LibUCW? Když jsem to před lety psal, bylo výrazně rychlejší oproti glibc, tak by bylo zajímavé zjistit, jestli to i s aktuální glibc platí.