Wie beende ich einen TThread freundlich und notfalls gewaltsam?

[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;

[Medium]

Ich kann Günthers Ansinnen schon gut verstehen. Wir haben auch Software im Einsatz, bei der die aller aller erste Prio ist, dass es LÄUFT. Es gibt Threads, die mit anderer Hardware via TCP sprechen. Leider verhält sich die Zugriffs-Lib (eine externe DLL) nicht immer so arg zuverlässig, so dass es z.B. beim Herausziehen des Netzwerkkabels durchaus passieren kann, dass ein Kommunikationsversuch bis in alle Ewigkeit wartet. Auch, wenn man das Kabel wieder rein stöpselt. (Das ist ein Beispiel, ich will jetzt nicht von euch hören, wie ich das Einstecken des Kabels von Windows mitgeteilt bekomme.) Da es für uns nicht wirtschaftlich ist diesen in 2 Jahren 1 Mal vorkommenden Fall damit zu behandeln, dass wir die externe (in C geschriebene) Lib a) verstehen und b) debuggen und dazu noch eine entsprechende Compilerumbegung zu erstellen (wir nutzen sonst kein C), war die "freundlichste" Lösung: Ein weiterer Thread als Watchdog, die den anderen nach einem Timeout im Zweifel per WinAPI wegballert und neu startet. (Solle dann immer noch keine Verbindung bestehen, wird dort zumindest brav eine entsprechende Rückmeldung gegeben.)

Bei aller Liebe zum Richtigmachen: Stellt keinem in Abrede, dass es wirtschaftlich sehr vorteilhafte, verhältnismäßige, und gar funktional vertretbare Fälle gibt, zu dessen Ursachen man ggf. nichtmals Zugang hat. Man muss natürlich sehr genau abwägen, und wissen was im schlimmsten Fall dabei schief gehen kann. Wenn aber 24/7 Funktion ohne Aufsicht das Credo ist, und man es in JEDEM Fall sicher stellen muss selbst wenn eine Handgranate im Server explodiert, dann ist ein weggeschossener Thread mit sauberem Neuaufsetzen die beste Alternative zwischen möglicherweise Wochen an (unbezahltem) Entwicklungsaufwand in Fremdcode in einer Sprache von der man nicht viel mehr als den Namen und grobe Züge kennt, und unvorhersehbaren aber immerhin sauberen Totalausfällen. Zumindest wenn man mit dem Programm nicht gerade eine Rakete oder ein AKW steuert.

Das akademische Ideal sollte nach Möglichkeit immer angestrebt werden, in der echten Welt gibt es aber leider auch so Sachzwänge wie Deadlines, Budgets und ggf. auch einfach andere Prioritätensetzung als eben das betroffene kleine Subsystem. Ich will üble Hacks hier nicht proklamieren, ich hoffe dass ich nicht so verstanden werde! Aber gerade bei Threads, die "von aussen" weggehängt werden bin ich ein wenig gebranntes Kind, und kann den Sinn und Nutzen einfach voll verstehen.

Wenn keine IPC oder andere externe Kommunikation dabei ist, schaut es wieder etwas anders aus: So lange ich mich voll und ganz in Delphi bewege, kann ich solche Sachen quasi immer hübsch und sauber behandeln. (Ausnahme: Nur als DCU vorliegende Komponenten, die eine while true do... Schleife haben.) Wenn man nach dem Verursachenden Aufruf einfach nicht mehr dazwischen kommt - ja was bleibt einem denn anderes!? Also bitte ein wenig mehr piano hier. Die Frage ist legitim, das Mittel je nach Fall auch. Der Zweck ohnehin.