[LUGA] Mit freundlicher Unterstützung von:
Linux New Media AG

Mail Thread Index


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [luga] EOF bei seriellen Verbindungen





2017-04-06 12:55 GMT+02:00 Bernd Petrovitsch <bernd@petrovitsch.priv.at>:
On Wed, 2017-04-05 at 17:20 +0200, Michael Lausch wrote:
> Oooops, hab VMIN=1 uebersehen.
>
> VMIN=1 sollte eigentlich verhindern dass ein read()  0 bytes returniert.
> Aber mit VMIN=1 und VTIME=0  kann der read() call indefinitly blockieren
> (wenn nix auf der seriellen schnittstelle empfangen wird), und der select()

Ja - und nein: Der Filedescriptor ist O_NONBLOCK und hängt hinter einem
select().

> call ist eigentlich unnötig. Zumindest für den read() vom tty. KA ob noch
> andere filedescriptoren mitspielen.
>
> ich persoenlich wuerde VMIN auch auf 0 setzen und wenn der select() call
> returniert und das tty daten hat, in einer loop read() aufrufen, bis 0
> bytes gelesen wurden.
> So wie man es auch mit non-blocking sockets macht.

Der Buffer ist groß genug, daß da alle anstehenden Bytes gelesen werden
können - sind eh höchstens 8 Byte.

> das wuerde auch dein derzeitiges problem loesen. es gibt dann kein EOF
> mehr.

Hmm, das heißt "0 Bytes" auch nicht mehr EOF - wenn ich das richtig
verstehe, oder?

 
Grüße an die Manual Page von read(2) und den Absatz "RETURN VALUES";-)

Alles ist ein file, ausser es ist keines ;-)
 

Hmm, aber nach dem 1. Mal read() == 0 ist dort nie wieder was an Daten
angekommen (und die andere Seite hat nachweislich welche geschickt).


 
Va. auch deshalb hab ich da "da ist ein EOF auf der seriellen Leitung"
diagnostiziert.
Dort ist vorher nicht mal irgendein Log-Output erzeugt worden (und ich
logge auch alle Stellen/Situationen, v.a. die nie passieren
können/werden, weil sonst findest sowas nie) und das hätte keiner
gemerkt, wenn das read() einmal - oder auch oft;-) - mit == 0
zurückkommt und dann wieder alles ganz normal.

loggst du die return werte vom read() call? ist der immer 1? oder ist der >1 just before
der "fehler" (read retruns 0) auftritt?

      > > 5) select() returns because of 3

    
Hmm, wenn 4) alles liest, sollte - single-threaded - 5) wegen dieses
     Fds eigentlich nicht returnen, oder?

Das stimmt nur, wenn es keine "race" condition im kernel zwischen select() und dem tty interface
gibt.


anderer shot in the blue:
ein anderes thread macht den fd zu, was ein bug in der applikation ist.

kann man ein strace() machen und alle syscalls mitschreiben? remote vielleicht?



powered by LINUX the choice of a gnu generation
linux user group austria;
Suche
Suche
Letzte Änderung:
webmaster@luga.at
April 2017