🚀 go-pugleaf

W dniu 16.07.2020 o 16:04, heby pisze:
> Cześć.
> 
> Mam named pipe (mkfifo).
> 
> Po jednej stronie ktoś robi 1000000 == ::write (pointer, 1000000);
> 
> Po drugiej stronie ktoś robi 1000000 == ::read (pointer, 1000000);
> 
> Wszystko działa, dostaje dane.
> 
> I przychodzi kernel 5.6.x gdzie "coś naprawiono w rurkach".
> 
> https://www.phoronix.com/scan.php?page=news_item&px=Linux-Pipe-Parallel-Job-Opt
> 
> 
> I teraz, ku mojemy zdziwieniu, dostaje:
> 
> size = ::read (pointer, 1000000);
> 
> Gdzie size jest 61578.
> 
> Coś podejrzanie blisko rozmiarowi bufora rurki, czyli 64k.
> 
> Manula klęczy na kolanach i zapewnia mnie że read w trybie bookującym
> nigdy nie wyjdzie z innym size niż kiedy jest fatal lub INTR, ale
> nawet wtedy size jest -1. Stackoverflow nieśmiało mu przytakuje.
> 
> A tu read wychodzi sobie w połowie czytania zwracając częśc danych ...
> 
> O rzesz...
> 
> Ja mam buga/zaćmienie czy Torvalds odwalł dziadówę w kernelu?


 Nikt jeszcze nie odpisał, to może ja się podzielę swoim
przemyśleniem: jeśli "::read" to odpowiednik read(2) (a pytam, bo
brakuje parametru), to jeśli mogłeś zapisać milion bajtów i od razu
odczytać też milion, to masz dość wydajny system lub szczęście, że nic
nie przeszkadzało w trakcie (lub jeszcze jakieś czynniki).
 Generalnie, read() powinno umieszczać się w pętli i czytać tyle razy,
aż uzbiera się tyle danych, ile się chciało od początku.
 Być może najnowsze zmiany w jądrze po prostu to ujawniły.

-- 
Pozdrawiam/Regards - Bogdan                     (GNU/Linux & FreeDOS)
Kurs asemblera x86 (DOS, GNU/Linux):            http://bogdro.evai.pl
Grupy dyskusyjne o asm:  pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
www.Xiph.org www.TorProject.org  Soft(EN): http://bogdro.evai.pl/soft