Wie beende ich einen TThread freundlich und notfalls gewaltsam?

[Der schöne Günther]

Hallo-

Zum immer näher rückenden Wochenende möchte ich Euch noch eine Freude mit einer Thread-Frage machen, ich hoffe, Ihr habt die heutige Frage zum Thema Threads noch nicht vermisst.

Folgendes weiß ich bereits:

1. Der TThread sollte sich immer selbst beenden indem die Methode Execute endet.
2. Um herauszufinden, ob der TThread nun wirklich endgültig tot ist, kann man mit dem Setzen der onTerminate -Methode bewerkstelligen. Diese Methode setzt z.B. eine Variable done auf True

Das Problem:
Der Thread ackert sich stellenweise durch Aufrufe die gerne mal eine Viertelsekunde blockieren. Ich möchte einstellen, dass sich der Destruktor des Objekts dem der TThread "gehört" (der TThread ist eine innere Klasse) sich nur eine bestimmte Zeit geduldet und dann rabiat wird.

Ich finde nichts, was TThread anbietet, nur die ultimative WinAPI-Funktion TerminateThread . Ja, der Thread steckt möglicherweise in einem kritischen Abschnitt. Ja, der Thread hat möglicherweise das Betreten kritischer Abschnitte verursacht, von denen ich nichts weiß.

Aber etwas besseres fällt mir nicht ein. Und es gefällt mir nicht, letztendlich doch eine WinAPI-Funktion anfassen zu müssen, aber das ist nebensächlich.

Es läuft also folgendermaßen ab:

Delphi-Quellcode:

destructor TMeineKlasse.Destroy;
const
   waitIterations: UInt = 500000;
var
   waitCounter: UInt;
begin

   // Sei freundlich zum Thread
   pollingThread.Terminate();

   waitCounter := 0;
   // Die 500.000 Iterationen sind sind praktisch immer zu wenig
   while (not pollingThread.done) and (waitCounter < waitIterations) do begin
      // Werde ich im Endeffekt wahrscheinlich nicht verwenden, das Objekt 
      // soll sich dem komischen Application-Objekt nicht herumplagen:
      Application.ProcessMessages(); 
      
      Inc(waitCounter);
      Sleep(0);
   end;

   // Thread hat sich nicht in geforderter Zeit beenden können
   if waitCounter = waitIterations then
      //Keine Ahnung bzgl. ExitCode, Null passt sicher immer
      TerminateThread(pollingThread.Handle, 0); 

   [Weiteres Aufräumen]

   pollingThread.Free();
   myCriticalSection.Free();

   inherited Destroy();

end;

Habe ich das so richtig gemacht? Natürlich kann man sich darüber streiten, wie schnell man so rabiat werden sollte, aber die Hintertür möchte ich mir auf jeden Fall offen lassen. Wer weiß, vielleicht hat sich der Thread ja auch aufgehangen...

[Furtbichler]

Alles Mist.

Sorge einfach dafür, das der Thread ordentlich terminiert. Alles andere ist absoluter Müll. Ich weiß, wovon ich rede, ich wollte das selbst mal so machen. Aber es ist bescheuert, glaube mir.

[Der schöne Günther]

Ich tue alles menschenmögliche. Und notfalls hänge den Hauptthread auch drei Sekunden auf um so lange auf den Thread zu warten.

Aber irgendwann muss doch wirklich mal Schluss sein?

Alternativ schleppe ich das TThread-Objekt bis zum Schluss als Speicherleiche mit, allerdings könnte das Objekt durchaus mehrere male am Tag zerstört und neu erstellt werden und die Software muss mehr oder weniger 24/7 laufen
Irgendwann ist da dann auch mal eine Grenze erreicht...

[tsteinmaurer]

Du musst im Execute des Threads regelmäßig das Terminated Flag abfragen und z.b. mit Exit rausspringen. Im aufrufenden Thread (Main-Thread?) rufst du nach Terminate einfach die WaitFor Methode des Thread-Objekts auf. Dies hält dir dann den aufrufenden Thread solange an, bis der Thread beendet wurde. Wenn du FreeOnTerminate := False des Threads gesetzt hast, dann musst du das Thread-Objekt auch noch mit Free freigeben.

[Der schöne Günther]

Danke für die Antworten.

Wie gesagt, wie man es richtig macht, habe ich anscheinend verstanden.

Jetzt geht es um den Fall, dass im Thread etwas falsch läuft. Dass er möglicherweise nie dazu kommen wird, sich um sein Terminated zu scheren da er irgendwo hängt oder möglicherweise abgestürzt ist.

[QuickAndDirty]

Zitat von Der schöne Günther:

Danke für die Antworten.

Wie gesagt, wie man es richtig macht, habe ich anscheinend verstanden.

Jetzt geht es um den Fall, dass im Thread etwas falsch läuft. Dass er möglicherweise nie dazu kommen wird, sich um sein Terminated zu scheren da er irgendwo hängt oder möglicherweise abgestürzt ist.

Easy! Mach ne Anwendung draus. Wenn die nicht auf IPC reagiert...kannst sie terminieren.

[Bummi]

Du kannst ja mal hier nachlesen TerminateThread function warum man einen Thread nicht einfach "killen" sollte.

[Der schöne Günther]

Das habe ich natürlich schon alles verschlungen

Wie gesagt: Die Methode soll - Bei allem was heilig ist! - natürlich nicht Standard sondern nur der allerletzte Ausweg sein. Quasi ein sinkendes Schiff dessen letzte Rettung es ist, die Passagiere von Bord zu werfen damit wenigstens die Mannschaft noch heil nach Hause kommt.

(Oder so ähnlich)

[Furtbichler]

Nee, Günther.

Programme sollen einfach richtig sein. Wenn da was irgendwie ne viertel Stunde rumrödelt und vielleicht 'abgestürzt' ist, dann hast Du einfach irgendetwas nicht richtig gemacht. Nichts stürzt einfach so irgendwie irgendwo ab. Programme sind blöderweise deterministisch. Leider wollen wir (Programmierer) das nicht wahrhaben.

Sich damit abzufinden, das irgendwas irgendwie ab und zu mal abstürzt ist ...

nee, Günther.

[Bjoerk]

Hallo schöner Günther,

wo hast du denn das Logo, das einem so herrlich die Augen rausgebrannt hat?

Ich benutze Threads vergleichsweise selten, aber wie wär's mit 2 Events.

Delphi-Quellcode:

procedure TMyThread.Execute;
begin
  try
    try
      if Assigned(FThreadActive) then
        FThreadActive(Nil);
      ..
    except
      on E: Exception do
        ShowMessage('Interner Fehler TMyThread');
    end;
  finally
    if Assigned(FThreadInactive) then
      FThreadInactive(Nil);
  end;
end;