Hallo,
wenn der Thread zum Auslesen da sein soll, würde ich folgendes Prinzip verfolgen (als Denkanstoß)
- Thread liest Daten aus der Schnittstelle in einen "eigenen" Puffer und informiert die Anwendung per Message (selbstdefinieren als Information darüber, dass in dem Puffer neue Daten da sind und an welcher Stelle sie stehen (Puffergröße ausrechnen z.B. auf mind. eine Sekunde Zwischenspeicher)
- Thread-Klasse selber hat z.B. eine Funktion Abbruch oder Stopp. Intern wird hierbei TEvent verwendet -> Grund siehe unten
- In der Execute-Methode machst du ein WaitForMultipleObject und "wartest" dort sowohl auf die Schnittstelle (Kann man direkt darauf warten) bzw. auf das TEvent-Object) und entscheidest dann entsprechend Dein verhalten (lesen oder eben abbrechen).
Vorteile:
- Entkopplung des Lese/ Wartezyklus von der Applikation -> die Applikation kann sich also um "ihre" arbeit kümmern
- Daten werden (nochmals) gepuffert für die Anwendung und der Thread wird nicht von der "Verarbeitung" der Daten durch die Applikation aufgehalten (Datenverlust)
- Nicht so Performancelastig, da der Thread wegen WaitForObject nicht so viel Zeit des Prozessors verbraucht wie eine Endlosschleife in einer Applikation
Nachteil:
- Höhere Aufwand der Programmierung
- Einarbeiten in das Thema Threads und deren Eigenarten (FreeOnTerminate/Syncronized ...)
- Erzwungene Trennung und dadurch entstehender Overhead
Viel erfolg dabei
Gruß, Chris