Hallo,

ich habe ein Problem wenn ich einen Thread vorzeitig beenden will.

Ich lasse den Thread in einer For Schleife einige Daten in ein TStringGrid eintragen.
Dies kann bis zu 10 Sekunden dauern. Damit die Form dabei nicht einfriert habe ich ein Application.ProcessMessages drinnen.

Möchte ich nun aber nach 5s schon abrechen indem ich Terminate und WaitFor aufrufe belibt es bei WaitFor stehen. Wenn das Update des TStringGirds fertig ist kann ich ohne Probleme den Thread beenden.

Ein Versuch auf diese Art geht nicht:

markieren

Delphi-Quellcode:

if not Terminated then
Application.ProcessMessages

Das Terminated bleibt auf False und dadurch bleibt es wieder hängen.

Application.ProcessMessages gefällt mir sowieso nicht aber wie kann man ansonsten ein "angebliches" Einfrieren der Anwendung verhindern?

Wie lässt Du denn die Daten in das Stringgrid eintragen, hoffentlich synchronized...
Der Thread muss das Terminated beachten, wenn Du eine Schleife hast könnte das so aussehen.

markieren

Delphi-Quellcode:

i := 0;
While (i < 10) and not Terminated do
  begin
    Tuwas;
    Synchronize(MeineThreadGridBefüllmethode);
    inc(i);
  end;

Vielleicht liegt auch eine gedankliche Vermischung vor?
Wie ist denn Dein Thread gestaltet? Hast Du ein eigene Thread-Objekt abgeleitet oder nutzt Du tatsächlich wie es aussieht Application.ProcessMessages als Thread?

Leider kann man Deinem Code-Snippet keine Angaben entnehmen.

Gib mal den gesamten Code vom Thread und vom Befüllen des StringGrids.

Die lange Zeit für das Befüllen kann auch daher kommen, dass du das StringGrid nicht mit BeginUpdate/EndUpdate auf eine Menge Daten vorbereitest.
Für dieses Befüllen würde ich mit Queue statt mit Synchronize arbeiten (warum soll der Thread warten, bis die Daten im StringGrid angekommen sind)

Warum wartest du überhaupt mit WaitFor auf den Thread?
MyThread.FreeOnTerminate := True und der entfernt sich selber aus dem Speicher.
Die ThreadVariable MyThread kannst beim Event OnTerminate auf nil setzen und gut.
Oder du führst ein eigenen Event ein OnDestroy und setzt dabei MyThread auf nil.

Application.ProcessMessages in einem Thread aufzurufen ist absolut tabu!

Zitat von Sir Rufo:

Application.ProcessMessages in einem Thread aufzurufen ist absolut tabu!

Genau das meinte ich auch mit gedankliche Vermischung. Es werden für Anfänger gern mal Threads mit Application.ProcessMessages oder Application.OnIdle verglichen, um dann zur Klasse TThread überzuleiten.

Daher dachte ich, auf diese Weise könnte sich ein Fehler eingeschlichen haben. Schließlich dürfte die GUI bei Ablauf eines zusätzlichen Threads eben genau nicht einfrieren, ansonsten würde das ganze ja keinen Sinn ergeben.

Er hat definitiv einen Thread benutzt, denn sonst macht Terminated und WaitFor keinen Sinn.

Und wenn das StringGrid ständig mit neuen Daten befeuert wird und dabei ein Neuzeichnen nach sich zieht dann ist die Anwendung ganz schön am kochen.
Wenn im Thread jetzt auch noch jedes Mal Synchronize aufgerufen wird, dann kann ich mir den Thread auch sparen.

Besser wäre es, den Thread die Daten komplett holen zu lassen und dann in einem Rutsch an das StringGrid zu übergeben.

Es könnte aber zusätzlich auch noch folgender Fehler vorliegen:

markieren

Delphi-Quellcode:

MyThread := TMyThread.Create( True );
MyThread.Execute;

Zitat von Sir Rufo:

Er hat definitiv einen Thread benutzt, denn sonst macht Terminated und WaitFor keinen Sinn.
[/DELPHI]

Stimmt, das war mir entgangen.

Hier noch der Aufbau und wie es abläuft:

Ich erstelle mir einen ClientThread. Dieser ClientThread hat einen Indy 10 TCP Client.
Der ClientThread überprüft natürlich bei jedem Durchlauf ob der InputPuffer was enthält.

Nach dem Verbinden des TCP Clients kommen viele Daten rein. Der Thread überprüft auch ob der große Ansturm der Daten vorbei ist.
Dies macht er indem er überprüft ob in den letzten 3 Sekunden keine Daten mehr angekommen sind.
Sind die 3 Sekunden noch nicht verstrichen werden die Daten in eine Temp-Tlist gefüttert.
Jedoch ändert sich der Status des Clients bei jedem Empfang (Download/Upload/Anzahl der Daten).
Die Client Informationen sind auch in einem TStringGrid der VCL. Also bei jedem ändern der Daten wird ein Synchronize des Client-TStringgrid gemacht um die Daten in der VCL aktuell zu halten.

Das TStringGrid wird also bearbeitet, dann noch die Spaltenbreite angepasst und dann ein Repaint des TStringGrids durchgeführt. Danach wird ein Application.Processmessage durchgeführt um die VCL nicht einfrieren zu lassen. Die Anzahl der Daten die der Client erhält ist unbekannt. Daher das überprüfen mit den 3 Sekunden.
Erhält der Client jetzt 600 stk Daten wird das Client-TStringGrid mit Synchronize auch 600 mal upgedated um die Info im TStringGrid aktuell zu halten.
Eine Möglichkeit wär, wenn ich statt Application.ProcessMessage den Thread nach dem Synchronize mit einem Sleep still zu legen.
Jedoch führt das dann zu einer Verzögerung zwischen dem Empfang der Daten.

Zitat:

Und wenn das StringGrid ständig mit neuen Daten befeuert wird und dabei ein Neuzeichnen nach sich zieht dann ist die Anwendung ganz schön am kochen.
Wenn im Thread jetzt auch noch jedes Mal Synchronize aufgerufen wird, dann kann ich mir den Thread auch sparen.

Besser wäre es, den Thread die Daten komplett holen zu lassen und dann in einem Rutsch an das StringGrid zu übergeben.

So ähnlich habe ich es bereits. Die erste Flut von Daten wird in eine Temp-TList gegeben. Ist der große Ansturm vorbei wird die Temp-Tlist in die Hauptliste übergeben. Hierführ wird nur einmal Synchronize verwendet da die Liste in einem Schwung hinzugefügt wird.

Jedoch habe ich keine Lösung dafür wie ich die Client Zeile im TStringGrid up to Date halte!?

Edit: Habe nun das Application.ProcessMessage beim Client-TStringGrid rausgenommen. Dafür ein Sleep(0) nach dem Synchronize im Thread. Jetzt kann ich Jederzeit abbreechen ohne das die Anwendung einschläft.
Die VCL reagiert noch. Zwar etwas träge aber ok... Kann man das noch verbessern?

Was meinst Du mit Client-Zeile im TStringGrid? Ist dort eine Angabe zum aktuellen Status Deines TCP-Clients (Download/Upload)?
Falls es so ist, pack das doch in ein Lebel oder ein StatusBar-Panel, das ist immerhin schneller gezeichnet als ein komplettes, möglciherweise randvolles TStringGrid.

Was wird denn übder den Upload geschickt? Auch Daten oder verbirgt sich dahinter die Abfrage ob mehr Daten kommen?

In welchen Abständen kommen Daten an, bzw. gibt es längere Wartezeiten zwischen den einzelnen Datendownloads?

Möglicherweise würde es Dir helfen Up- und Download zu trennen und die entsprechenden Threads über ApplicationEvents zu starten?

Jeder Client hat eine Zeile im TStringGrid.
Jede Zeile hat dann Infos vom Client wie Down/Upload, Verbunden seit, IP, Port.

Die maximale Idle Zeit wo kein TCP Verkehr stattfindet sind so ca. 30s.
Dies ist bedingt durch eine KeepAlive Message.

Zu den Queues:
Um Threads untereinander zu Snchroniseren benutze ich derzeit TThreadList.
D.h. ein Thread füllt Daten in die TThreadList eines anderen Threads.
Beim nächsten Durchlauf überprüft der Thread ob Daten in der TThreadlist Daten vorhanden sind und arbeitet diese dann ab.

Gibt es zu den Queues ein schönes Beispiel oder wie kann man ansonsten einfach Threads untereinander Synchronisieren?

Ich hatte es vorher mit PostThreadMessage versucht, aber bei wenn ein Thread über ca. 300 Nachrichten (in kurzen Zeitabständen) an den anderen Thread geschickt hatte gab es Probleme.