Zitat:
Beim oben genannten Thread kann es allerdings kein 2tes Event signalisieren, weil ich ja gar nicht weiss wann die Gegenseite Daten ins Socket schickt. Deshalb die Idee mit WaitforSingleObject.
Doch das gibt es auch da. Denn deine Socket Komponenten gehen übers WinSock
API des
OS und das stellt asynchrone Kommunikation (Overlappings und Events) zur Verfügung. Das Problem sind die
VCL Komponenten die du benutzt, bzw. genauergesagt die Unfähigkeit der Programmierer die diese
VCL gecodet haben. Harte Worte ich weis aber es ist halt eine Tatsache.
Du solltest jetzt mal schauen ob deine Komponenten ein Eventbasiertes ReadLn() oder so unterstützen.
Der "Aufwand" lohnt sich auf alle Fälle. Denn ohne diese Events bleibt dir nur noch dein Weg über ein zeitliches Polling. Bei 250ms Timeout heist dies das im Durchschnitt dein Thread ca. 125ms zeitverzögert die Socket ausliest. 125ms dauert ein Traceroute um die halbe Welt über mehrere Server hinweg. In 125ms überträgt man in einem 100MBit LAN bis zu 1 Megabytes an Daten. Du hast also mit deinen 250ms bzw. dann durchschnittlich gerechnet 125ms ein sehr schlechte Antwortzeit. Wenn du nun darüber nachdenkst das auch zb. 50ms zu verkürzen dann überschreitest du einen Breakeven Point zwischen schnelle Reaktionszeit und zeitlichem Aufwand nachzuschauen ob was im Socket empfangen wurde. Denn die Anfrage ob der Socket Daten enthält wird selber pa Millisekunden dauern können. Sagen wir mal extrem gerechnent 10ms. Dhj. alle 50ms erwacht dein Thread und benötigt dann 10ms um festzustellen das NICHTS im Socket liegt. Ein sehr schlechtes Laufzeitverhalten und dein Thread frisst dann enorm Rechenzeit für NICHTS. Das sind dann die Programme die uns alle so nerven, sie blockieren unsere Rechner, erzeugen enorme Wartezeiten beim Booten etc.pp. und das alles für NICHTS und nur weil die Programmierer die EINFACHE Variante gewählt haben (im Grunde genommen aber Mist gemacht haben).
Wie du siehst in jedem Falle wäre ein Eventbasiertes System vorzuziehen. Mit einem Polling, egal wie, handelt man sich nur Performanceprobleme zu ungunsten des gesamten Systemes ein.
Beispiel: Warum gibt es in den
INDY Komponenten eine idAntiFreeze Komponente ?
Wenn
INDY intern immer mit Events und Overlapping in seinen Threads arbeiten würde dann kann die Anwendung/der Prozess garnicht mehr einfrieren, wie auch ? Ich möchte jetzt nicht die INDYs schlecht machen, es ist ein großartiges Tool, und ich bin mir auch nicht 100%'tig sicher wie deren Thread Management arbeitet, aber obige Frage ist definitiv eine berechtigte Frage !
Gruß Hagen