c# - select()

[gorba]

hallo

ich wollte fragen ob jemand folgendes Problem kennt:

- kernel 2.6.8
- sprache: c#

mein select(), dass den FD von ttyS0 überwacht meldet mir, dass Daten lesbahr sind, nachdem das EOF (vom vorher gesendeten File) erreicht ist. somit sind all meine bemühungen sinnlos, da mein Programm immer annimt, dass Daten lesbahr sind.

Jemand schon erfahrung damit gemacht oder kann mir tipps geben?

thx für alle bemühungen, schon im voraus =)

[f0rtex]

Auszug aus Advanced Programming in the UNIX Environment:


If we encounter the end of file on a descriptor, that descriptor is considered redable by select. We then call read and it returns 0, the way to signify end of file on UNIX systems. (Many people incorrectly assume that select indicates an exception condition on a descriptor when the end of file is reached)


Grüsse

[gorba]

das ist mir schon klar. aber das Problem is ja, dass mir mein system glaubhaft machen will, dass noch daten verfügbar sind.
select() MELDET, dass Daten zum lesen vom FD vorhanden sind. Und read() LIEST zufällige Bitmuster aus (wenn read 0 als return Value melden würde, hätte ich ein Bug im Programm. Ichbekomme aber von read 1 oder 2 als value zurück, das heisst, das read 1 oder 2 bytes ausgelesen HATT). das sind zum teil Linefeeds und zum teil widerholungen des gesendeten Bitmusters. Um Übertragungsfehler auf einer Leitung zu testen sind solch unlineare Muster absolut tödlich, da mein Programm diese als Übertragungsfehler auswertet.
Es schein sich tatsächlich um einen Bug im kernel 2.6 zu handeln.
Ich habe keine erklärung oder lösung zu diesem problem gefunden, darum bin ich momentan dran einen Linux-Device Treiber für die com schnittstelle zu schreiben.

[gorba]

für alle die das gleiche problem hatten/haben werden:
keine lösung oder ursache gefunden. muss am device tereiber liegen oder aber bug im kernel 2.6
umgangen mit: fd auf asynchron geschaltet, signal installiert, dem prozess erlaubt das signal zu empfangen. nun überprüft das signal den asynchronen fd aus möglichen input und setzt schleifenbedingung auf true wenn daten lesbar sind.

grez

[pucki]

für alle die das gleiche problem hatten/haben werden:
keine lösung oder ursache gefunden. muss am device tereiber liegen oder aber bug im kernel 2.6
umgangen mit: fd auf asynchron geschaltet, signal installiert, dem prozess erlaubt das signal zu empfangen. nun überprüft das signal den asynchronen fd aus möglichen input und setzt schleifenbedingung auf true wenn daten lesbar sind.

grez

evtl wären die entwickler der betreffenden codesegmente daran interessiert, immer vorausgesetzt, dass in den rfc's nicht genau das verhalten so spezifiziert wird.

gruesse

[gorba]

habe mich mit mark mielke (linux kernel entwickler) über das thema unterhalten, er gab mir den link zur folgenden disskussion, in der es genau um das problem gieng. sie sind auch zu dem entschluss gekommen, select() liefere falsche resultate. evt. wird es in einer neuen kernelversion behoben sein.

Link zur diskussion: http://www.ussg.iu.edu/hypermail/linux/kernel/0410.1/0459.html