Frage: X_Read erzwingen / direkt aufrufen?

[viegener]

Folgende Frage:

Kann ich in einem Modul X aus meiner X_Set funktion auch X_Read aufrufen um Daten zu verarbeiten?

Hintergrund:

Ich habe ein Modul, dass über DevIO Daten aus einem Device/Port liest und schreibt. Normalerweise wird also der Aufruf von X_Read in meinem Modul ganz normal über vorhandene Daten im descriptor getriggert.

Allerdings wird auch beim Absetzen von Kommandos aus dem descriptor/file handle gelesen um den Fehlerstatus entsprechend synchron setzen/zurückgeben zu können. Deshalb werden aber gelegentlich bereits Daten gelesen die eigentlich normal über X_Read gelesen werden sollten und nicht zum Returncode gehören.

Also müsste ich entweder aus der Set funktion auch X_Read aufrufen oder auf andere Art die Daten wieder in den Puffer für den filedescriptor zurückstellen, damit die Daten beim X_Read aus der Main-Routine behandelt werden.

Danke schonmal für jede Hilfe,
Johannes

[rudolfkoenig]

Moegliche Alternativen:
- das wesentliche Teil von ReadFn (bis auf sysread) wir in eine neue ParseFn geschoben, die sowohl vom ReadFn, wie auch vom SetFn aufgerufen wird.
- ReadFn wird mit einem zusaetzlichen Parameter aufgerufen (die gelesenen Daten), wenn gesetzt, dann wird kein sysread/etc mehr abgesetzt, sondern mit diesen Daten gerechnet.

[viegener]

Ja, Danke, das kann ich auf jeden Fall so machen.
Ich verstehe das aber auch so, dass es keine Einwände gibt die eigene ReadFn aus dem Set herausaufzurufen (bzw. die entsprechende Verarbeitung anzustossen).

Bisher habe ich die "zuviel" gelesenen Daten bereits in einem INTERNAL abgelegt und in der ReadFn werden diese auch berücksichtigt. Ich mache den sysread dann mit 0.01s timeout um nur etwaige weitere Reste im Devicebuffer mitzubekommen. Habe aber keine Möglichkeit gefunden, die main-loop dazuzubringen die ReadFn aufzurufen, ohne dass Daten im filehandle/select vorliegen.

Vermutlich hatte ich zu kompliziert gedacht, denn ich suchte eine generische Möglichkeit, dass die main-loop benachrichtigt werden kann die ReadFn aufzurufen auch wenn im Filehandle/select keine Daten anliegen. Sowas wie das wantRead, dass in der mainLoop ausgewertet wird...

Wäre das eine sinnvolle Erweiterung, um Devices die Daten auf anderen Wegen (als select/filehandle) erhalten eine Möglichkeit zu geben dass sie signalisieren können, ich muss Daten verarbeiten?

So etwas wie eine - NeedReadFn, die Module definieren können und die von der mainloop aufgerufen wird um festzustellen, ob das Modul Daten vorliegen hat?




Es scheint ja so etwas wie $hash->{wantRead} zu geben

[rudolfkoenig]

Ich mache den sysread dann mit 0.01s timeout um nur etwaige weitere Reste im Devicebuffer mitzubekommen

Das sollte nicht notwendig sein, dafuer ist select da.

Wäre das eine sinnvolle Erweiterung, um Devices die Daten auf anderen Wegen (als select/filehandle) erhalten eine Möglichkeit zu geben dass sie signalisieren können, ich muss Daten verarbeiten?

Strenggenommen sollte man alles ueber den globalen select abhandeln. Allerdings habe ich auch selbst schon oefters Ausnahmen fuer die get Funktionen programmiert (CUL_ReadAnswer). Ist nicht sauber, und sollte in einer ruhigen Minute umgebaut werden. Hab nur noch keine Idee, wie

[viegener]

Ja, das war mein Fehler ich verwende schon select hier, der read mit timeout wird nur verwendet um nach Absenden eines Befehls die Rückmeldung zu bekommen.

Ich habe meine Read-Funktion jetzt umgestellt und rufe sie jetzt auch intern aus Set/Get auf, wenn Daten zu Verarbeitung anstehen, die bereits aus dem Device gelesen wurden, bisher gab es keine Probleme.

Interessant, Dein CUL_ReadAnswer ist ähnlich aufgebaut, wie meine Struktur, allerdings hatte ich die Rekursion übersehen, die ja (z.B.) durch das Verändern von Readings auftreten kann. Die habe ich nun hinzugefügt...