Hi nochmal, Bernd!
Am Fr, 2003-02-14 um 22.49 schrieb Bernd Walter:
[...]
> > Das ist allerdings eine gute Frage. Der Grundgedanke dabei war
> > Modularität und Wiederverwendbarkeit. Für eine schnelle praktikable
> > Lösung hast Du recht, da kann ich auch einen Timer benutzen, der bei
> > Ablauf die Ausführung der weniger aufwendigen Aufgabe anstößt.
>
> Modularität ist natürlich eine Sache, ein weiterer Grund, warum du
> das mit Threads amchen solltest, weil die einfacher Modular zu
> halten sind.
> Ansonsten braucht man asyncrone Verarbeitung eigendlich immer dann,
> wenn die Verarbeitung mitunter länger dauern kann, als der Eingabe-
> zyklus.
> Dann hat man die Chance bei der Ausgabe einen Status zu überspringen.
> Aber auch in diesem Fall gibt es mehr als einen Lösungsansatz.
Ist hier anders rum, es kommen eher selten Meßwerte an und die
Verarbeitung geht schnell. Das kann sich aber ändern, wenn die später
noch anders weiterverarbeitet werden sollen. Also möchte ich primär die
Werte verhaften und mir jederzeit für die Auswertung irgendwas anderes
ausdenken können. Ich will halt die Meßwertaufnahme fertig schreiben und
ggf. an ein anderes 'Backend' koppeln können, brauche die jetzt aber
quasi sofort zur Anzeige.
> > Kniffelig wird es dann eben mit der Steuerung der Hauptsache, aber
> > select() sollte ja nur zurückkehren, wenn es etwas zu lesen gibt oder
> > das timeout abgelaufen ist. Das ist dann der Ereignismechanismus. Oder
> > verstehe ich was falsch?
>
> Vorsicht: select kehrt mitunter auch aus anderen Gründen zurück, z.B.
> bei errno == EINTR und errno == EAGAIN.
> Gerade heute erst wieder über ein Programm gestolpert, das sporadisch
> versagt hat, weil die Behandlung für den Fall vergessen wurde.
Selbstverständlich, ich hatte ja schon geschrieben, das ich 'timeout'
benutze, da muß man sowieso prüfen.
Danke soweit,
Marc
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Sat 15 Feb 2003 - 02:53:27 CET