[LUGA] Mit freundlicher Unterstützung von:
init.at

Mail Thread Index


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

Re: [luga] EOF bei seriellen Verbindungen



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";-)

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.

> 2017-04-05 14:51 GMT+02:00 Michael Lausch <mick.lausch@gmail.com>:
> > 2017-04-05 12:46 GMT+02:00 Bernd Petrovitsch
> > <bernd@petrovitsch.priv.at>:
[...]
> > "da kommt ein EOF daher" heisst read() returns 0?
> > select() ist edge triggered.

Ja, der Filedescriptor ist (neben einigen anderen) im select() und das
read() im Eventhandler (der nur aufgerufen wird, wenn das select()
behauptet, daß da Daten wären).

> > 1) byte arrives->select() returns.
> > 2) read() start execute
> > 3) byte arrives
> > 4) read() returns with 2 bytes.
> > 5) select() returns because of 3

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

> > 6) read() return with 0 bytes
> > 
> > oder ist die lesende app multithreaded und ein andere thread macht das
> > read()?

Das ist leider multi-threaded, aber von dem Fildescriptor liest genau 1
Thread an genau einer Stelle im Source (alles andere ist sowieso
doof;-) und derselbe Thread ist auch der, der im select() hängt (weil
ursprünglich war das single-threaded und durch anderen eingetretenen
Source ist das Ganze erst multi-threaded geworden).

> > epoll() ist level triggered und sollte das problem loesen koennen.

Kein epoll() o.a. neumodisches Zeug;-)
Das select() ist ja in irgendeiner uralten mainloop-Lib, die vermutlich
älter als  epoll() u.ä. ist;-)
Ja, die Lib gehört aus ganz anderen - applikativen - Gründen sowieso
ausgetauscht - und da braucht wohl mehr als einen Freitag nachmittag
dazu ....


On Wed, 2017-04-05 at 20:39 +0200, Steffen Nurpmeso wrote:
[...]
> Es gibt oder gab auch noch den FIONREAD ioctl, der die Anzahl an
> Bytes in der Queue zurück gibt, sodaß blockierendes I/O
> nicht-blockierend machbar ist.  Z. B. ("sir==ssize_t")

Abgesehen davon, daß da inzwischen ja weitere Bytes kommen könnten (bei
4800 Baud fetzt das ja auch so richtig;-), während andere Daten an
anderen Fds verarbeitet werden, muß man aber letztendlich beim read()
auch den Return Value anschauen und entsprechend etwas sinnvolles
machen - da hilft mir das Wissen vorher nichts, ob da jetzt 3 oder 4
oder 8 Byte kommen (und mehr kommen "auf einmal" nicht).

Thx to all BTW, 
	Bern d
-- 
Bernd Petrovitsch                  Email : bernd@petrovitsch.priv.at
                     LUGA : http://www.luga.at



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