wann wird die Message-Loop angehalten?

[yogie]

Hallo zusammen,

den Beitrag "Update-Vorgang in einen Thread auslagern" nehme ich hier mal zum Anlass eine Frage zu stellen, die mich schon lange beschäftigt. Was die Message-Loop bei Windows macht ist mir in groben Zügen bekannt und soweit ich weiß hat jedes Programm (Prozess?) seine eigene Loop.

Ich arbeite viel mit externer Hardware, die mir per serieller Schnittstelle Daten übergibt. Nun fällt mir immer wieder auf, dass trotz kontinuierlich eintreffender Daten, die Anzeige meines Programms stockt, wenn ich das Fenster verschiebe. Das erkläre ich mir so, dass die Message-Loop eben unterbrochen wird, wenn ich z.B. das Fenster mit der Maus verschiebe. Das ist aber nicht immer so, ich habe bloß nicht verstanden warum.

Weiterhin habe ich den Eindruck, das dieses Verhalten vom Betriebssystem abhängt. Unter WIN95/WIN98 war es meiner Meinung nach "schlimmer".

[himitsu]

Eine Message-Loop (die Abarbeitugsprozedur) hat nicht jeder Prozess
und andere Prozesse haben auch gern mal Mehrere davon.

Aber grundsätzlich kann jeder Thread eine Message-Queue bekommen.
Diese wird automatisch erstellt, sobald die erste Message an den Thread gesendet wird, bzw. wenn die erste Komponente (Window) in dem Thread erstellt wird.

In Delphi hat "standardmäßig" nur der Hauptthread eine Message-Behandlung, welche durch die VCL in der TApplication-Instanz behandelt wird (Application.Run, Application.ProcessMessages usw.),
aber es ist dennoch möglich auch in anderen Threads andere Messages zu behandeln.


Warum es manchmal hängen bleibt, vorallem gern beim Verschieben von Fenstern, auch bei der Konsole, ist halt eines der Mysterien.

Aber wenn der Thread nicht durch die VCL hängen bleiben darf, dann mußt du halt dein Konzept verändern/anpassen.
Einige Lösungen:

• Der Thread übergibt nicht die Daten, sondern die GUI/Hauptthread holt sich die Daten ab. (eventuelles Hängenbleiben umgedreht)
• Man gibt die Daten asynchron an VCL/Thread weiter. (eigene Queue, Events, Pipes, Windows-Message senden, oder Sonstwas, und nicht auf die Behandlung warten ... PostMessage<>SendMessage)
• Beim Senden wird mit Timeout gearbeitet, damit es nicht zu lange hängt, und versucht es dann halt später nochmal.
• ...

[yogie]

@himitsu
..danke für Deine Ausführungen, Mysterien sind ok, solange sie nicht durch mein eigenes "wundersames Wirken" entstehen.

Die Übergabe per Message habe ich schon in Erwägung gezogen. Ich würde dann in der (seriellen) Empfänger-Routine eine Message absetzen, die dann im VCL-Haupt-Thread empfangen wird. Wenn ich Deine Antwort richtig verstanden habe, solllte dann nichts mehr blockieren. Zum Verständnis: solange ich meine Form verschiebe, würden die Messages in der Schlange auflaufen und erst abgearbeitet werden, wenn die Verschiebung beendet ist?

[himitsu]

Jupp, wenn die Message-Queue nicht abgearbeitet wird, dann sammeln sich die Messages an und werden danach dann abgearbeitet.

Aber Achtung, die MessageQueue hat auch nur eine gewisse Größe und und wenn voll, dann voll und man kann nichs mehr dranhängen.
PS: Wer kennt noch von früher den Zustand, daß es plötzlich "bin voll"-warn-piept, wenn man bei einem hängenden Programm dennoch weiterhin auf der Tastatur rumhämmert oder mit der Maus rumklickt und das Programm mit Messages zugemüllt hat?

[hathor]

Zitat von yogie:

...Ich arbeite viel mit externer Hardware, die mir per serieller Schnittstelle Daten übergibt...

Physikalisch oder virtuell?

Evtl. Datenrate reduzieren oder im externen Thread/Programm Daten empfangen.

[Sir Rufo]

Wenn viele Nachrichten innerhalb kurzer Zeit eintreffen, dann sollte man über eine Dämpfung nachdenken.

Das menschliche Auge kann ca. 25 Bilder/Sekunde unterscheiden, da macht es also keinen Sinn, die Anzeige zu stressen, nur weil die Nachrichten schneller/öfter eintreffen.

Erreichen kann man das z.B. mit einem Timer der alle 40ms prüft, ob die Anzeige neu gezeichnet werden muss und dann eben auslöst => max. 25 x pro Sekunde wird die Anzeige neu gezeichnet.

Eine andere Möglichkeit ist die Verwendung einer internen Nachrichtenverteilung. Alle Nachrichten kommen in eine Liste und werden von einem Thread per Synchronize an den MainThread übergeben und dann aus der Liste entfernt. Der Trick ist jetzt, dass gleiche Nachrichten nur einmal in die Liste aufgenommen werden. Kommen also auf einen Schlag 1000 Nachrichten "MachWas", dann wird dem MainThread nur eine übergeben.

Dafür kann man einer TList<T> einen IComparer<T> mitgeben, der diese Gleichheit ermittelt und mit TList<T>.Contains fragt man das ab. Schon wird es wieder ruhiger an der UI-Front.

[yogie]

Die Datenrate ist nicht zu hoch, ca. 1 Sekunden Abstand zwischen den Satensätzen. Mir geht es hier aber auch vorwiegend um die Tatsache, daß gerade das Verschieben eines Fensters zur Unterbrechung der Aktualisierung im Fenster führt. Ich kann mir das nur so erklären, daß die Verschiebung die Message-Loop blockiert und alles Andere warten muß, bis die Verschiebung beendet ist. Falls noch jemand Details dazu kennt ... immer gerne gelesen.

[p80286]

Das Verschieben des Fensters wird auch über Messages realisiert.
da sieht es schon mal so aus als würde das Programm stehen bleiben.

Gruß
K-H

[yogie]

@hator
es ist schon eine echte (hardware) serielle Schnittstele, oder meinst Du jetzt virtuell im Sinne eines virtuellen COM-Ports der eigentlich durch einen USB-zu-seriell Adapter realisiert wird?

Letzteres ist oft der Fall und da passieren noch ganz andere Dinge.

Meine Blockierungsfrage bezog sich aber auf eine echte serielle Schnittstelle (COM-Port, RS232)