Wie beende ich einen TThread freundlich und notfalls gewaltsam?

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

[Der schöne Günther]

Bislang sah ich mich Selbst als Einmannwolfsrudel, aber als ich deinen Beitrag las wusste ich: Er gehört zu mir. Und mein Wolfsrudel ist um eine Person gewachsen.

Zwei Wölfe jagen nun zusammen durch die Wüste im Delphi-Land an der Grenze zur WinAPI auf der Suche nach Threads, Speicherlecks und blockierenden Kommunikationsroutinen, deswegen bringe ich heut Morgen einen Toast aus!

:party:

[sh17]

Also es gibt (foren)threads, die haben vorerst auch ohne lösung einen Wert der Unterhaltung ;-)

[Furtbichler]

Zitat:

Zitat von Medium (Beitrag 1208467)

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.

Ist schon richtig, aber die hemdsärmelige Notlösung ist immer das aller aller aller letzte Mittel. Und vorher sollte man genau(!) wissen, das es nicht anders geht.

Beim schönen Günther bin ich mir derzeit noch nicht sicher, ob er wirklich alle Möglichkeiten ausgereizt hat, schließlich scheint er bei Delphi noch ne ganze Menge lernen zu müssenwollen.

Zitat:

Ein weiterer Thread als Watchdog, die den anderen nach einem Timeout im Zweifel per WinAPI wegballert und neu startet.

So, und wie nun?

Ich habe in einem anderen Thread gewagt, zu behaupten, das ich auf Resourcenschutzblöcke verzichten kann, wenn ich (a) etwas ganz anderes demonstrieren will (z.B. Beispielcode), oder (b) an einer Stelle ganz genau weiß, das das Programm eh beendet wird, wenn's knallt (wozu dann den Speicher freigeben?). Der Thread ging -glaube ich- über 4 Seiten, weil niemand es verstanden hat. In diesem Forum sind von der schönen Norm abweichende Gedankengänge nicht gerne gesehen.

Ebenso sollte man hier gebetsmühlenartig darauf hinweisen, das man das nicht macht, aber wenn schon, dann eben so:... (Du bist am Zug ;-) )

Bei meiner TCP-Anwendung (Maschinenbau, Kommunikation mit MES, Schrottnetzwerk) passiert soetwas auch. Da hilft bei uns dann nur ein Kill-Prozess bzw. die Anwendung schießt sich selbst ab, zur Not wird sie von außen gekillt und wenn das nicht hilft (externe DLL, dieser Schrott), dann wird der Benutzer abgemeldet und durch das Autologin mit Autostart neu gestartet, das dauert eine Sekunde und man merkt das kaum.