Goto page Previous 1, 2, 3
Zbych
Guest
Thu Mar 08, 2018 8:32 am
W dniu 08.03.2018 o 00:10, Adam Wysocki pisze:
Quote:
Zbych <abuse@onet.pl> wrote:
2. read w trybie blokującym czeka na dane, jak wypnę w trakcie czekania
wtyczkę to przerywa czekanie zwracając 0, czego nie traktuję jako błąd.
Kolejne wywoływania read zwracają cały czas 0
Wartość 0 oznacza EOF ("koniec pliku", zamknięte połączenie, koniec
strumienia danych). To coś innego niż brak danych (bo wtedy jak sam
zauważasz blokujący read poczeka, a nieblokujący zwróci EAGAIN).
Skoro write potrafi zwrócić kod 'Input/output error', to spodziewałbym
się takiego samego kodu błędu po read. To nie jest chwilowy brak danych,
który później się pojawią.
Quote:
Problem polega na tym, że mam urządzenia z który tylko czytam dane
(skanery, klawiatury) i takie zachowanie read jest delikatnie mówiąc
irytujące.
Hmm, jak dla mnie jest prawidłowe. Po prostu read() nie ma prawa zwrócić
0, jeżeli urządzenie jest podłączone i działa, ale nie ma danych. Wartość
0 oznacza, że kanał komunikacyjny został zamknięty i dane się skończyły
(to nie to samo, co chwilowy brak danych, które mogą przyjść później, bo
strumień jest otwarty; gdy read() zwróci 0, to dane już nie przyjdą).
Zbych
Guest
Thu Mar 08, 2018 11:42 am
W dniu 08.03.2018 o 11:05, Adam Wysocki pisze:
Quote:
Zbych <abuse@onet.pl> wrote:
Skoro write potrafi zwrócić kod 'Input/output error', to spodziewałbym
się takiego samego kodu błędu po read. To nie jest chwilowy brak danych,
który później się pojawią.
Taka już jest konwencja read(). Chwilowy brak danych jest sygnalizowany
przez blokowanie lub EAGAIN, permanentny brak danych przez 0 (EOF). EOF
oznacza "zakończ pracę, bo więcej już nie odczytasz". Czy jest to błąd,
czy normalna sytuacja, to zależy od założeń.
Przykład z plikiem chyba nie jest najlepszy, bo EOF "teraz" nie znaczy,
że "za chwilę" się tam nic nie pojawi do dalszego czytania. Najprostszy
przykład to logi. EOF w przypadku czytania logów to na pewno nie jest
błąd, po którym nie masz innego wyjścia jak zamknięcie pliku.
Adam Wysocki
Guest
Thu Mar 08, 2018 12:05 pm
Zbych <abuse@onet.pl> wrote:
Quote:
Skoro write potrafi zwrócić kod 'Input/output error', to spodziewałbym
się takiego samego kodu błędu po read. To nie jest chwilowy brak danych,
który później się pojawią.
Taka już jest konwencja read(). Chwilowy brak danych jest sygnalizowany
przez blokowanie lub EAGAIN, permanentny brak danych przez 0 (EOF). EOF
oznacza "zakończ pracę, bo więcej już nie odczytasz". Czy jest to błąd,
czy normalna sytuacja, to zależy od założeń.
Zakładam, że wywodzi się to stąd, że read() / write() oryginalnie służą
do zapisu / odczytu plików. Gdy czytasz z pliku, to ten plik kiedyś się
skończy i nie jest to błąd, podczas gdy nieudany zapis do pliku zawsze
jest błędem. Przy strumieniach z urządzeń jest podobnie.
Po prostu odłączenie urządzenia jest traktowane jako koniec strumienia,
a nie błąd I/O.
--
[ Email: a@b a=grp b=chmurka.net ]
[ Web:
http://www.chmurka.net/ ]
Adam Wysocki
Guest
Thu Mar 08, 2018 2:29 pm
Zbych <abuse@onet.pl> wrote:
Quote:
Przykład z plikiem chyba nie jest najlepszy, bo EOF "teraz" nie znaczy,
że "za chwilę" się tam nic nie pojawi do dalszego czytania. Najprostszy
przykład to logi. EOF w przypadku czytania logów to na pewno nie jest
błąd, po którym nie masz innego wyjścia jak zamknięcie pliku.
Zazwyczaj jednak pliki czyta się od początku do końca, a po końcu zamyka.
Sytuacja, w której program przewiduje, że plik jeszcze urośnie, jest
nietypowa. Większość narzędzi Linuksowych standardowo tak się zachowuje.
Jak chcesz przeczytać log "od początku do anulowania" (a nie "od początku
do końca tego, co w nim aktualnie jest") to przecież nie używasz cat,
tylko tail -f.
Zresztą taki "follow" rodzi problem, jeśli plik zostanie w międzyczasie
przycięty, bo wskaźnik pliku nie przesuwa się do początku.
Inna sprawa, że nie da się usunąć pliku, który jest aktualnie otwarty
(można usunąć dowiązanie, ale inode zostaje do momentu zamknięcia), więc
takie zachowanie read() dla pliku ma sens. Czy ma dla urządzenia... widzę
argumenty i za, i przeciw, i pewnie można się kłócić i dyskutować, jak
powinno być, ale obecny stan jest taki, że read() zachowuje się tak, a nie
inaczej... podejrzewam, że ktoś to przemyślał.
--
[ Email: a@b a=grp b=chmurka.net ]
[ Web:
http://www.chmurka.net/ ]
Goto page Previous 1, 2, 3