Überschreiben von TThread.Terminate

[himitsu]

// override hier ja nicht nötig, da nicht virtual Genau falsch ... es muß heißen
"override hier ja nicht möglich, da nicht virtual"

Heißt also, du kannst es nicht überschreiben
Und TThread ruft nur das ihm bekannte Terminate auf (deines kennt er nicht).

Wie wäre es mit einem Eventhandler für OnTerminate?

[sirius]

Zitat von himitsu:

// override hier ja nicht nötig, da nicht virtual Genau falsch ... es muß heißen
"override hier ja nicht möglich, da nicht virtual"

Heißt also, du kannst es nicht überschreiben
Und TThread ruft nur das ihm bekannte Terminate auf (deines kennt er nicht).

Ganz richtig wäre: TThread ruft Terminate nie auf, deswegen muss es auch nicht virtual sein. Ein simples verdecken (reintroduce) reicht hier völlig aus.

Virtuelle Methoden sind ja nur wichtig, wenn von deiner Elternklasse in eine deiner Methoden gesprungen werden soll. Aber Terminate ruft man ja nur von außen auf, deswegen einfach verdecken, fertsch.

[Stevie]

Zitat von sirius:

Ganz richtig wäre: TThread ruft Terminate nie auf, deswegen muss es auch nicht virtual sein. Ein simples verdecken (reintroduce) reicht hier völlig aus.

Schonmal in den Destructor von TThread geguckt?

[sirius]

Zitat von Stevie:

Zitat von sirius:

Ganz richtig wäre: TThread ruft Terminate nie auf, deswegen muss es auch nicht virtual sein. Ein simples verdecken (reintroduce) reicht hier völlig aus.

Schonmal in den Destructor von TThread geguckt?

Ui, korrekterweise wäre dann ein Virtual sinnvoll, weil man sich sonst nirgendwo ins Terminate reinklinken kann.
Aber ein kurzes Üüberlegen, wann der Fall eintritt, sagt mir, dass man dann den Thread während des Betriebes von außen abschießen muss. Böse Sache, dass.

[jfheins]

Zitat von sirius:

Ganz richtig wäre: TThread ruft Terminate nie auf, deswegen muss es auch nicht virtual sein. Ein simples verdecken (reintroduce) reicht hier völlig aus.

Virtuelle Methoden sind ja nur wichtig, wenn von deiner Elternklasse in eine deiner Methoden gesprungen werden soll. Aber Terminate ruft man ja nur von außen auf, deswegen einfach verdecken, fertsch.

Wette ich um ein virtuelles Bier dagegen

Wenn man "von Außen" eine TThread Variable hat, und diese dann aber mit einem TmeinThread belegt und .terminate aufruft, wird trotzdem nur TThread.Terminate aufgerufen.

[MatthiasR]

Andere Frage: wieso kann ich in TThread.Terminate auf der (einzigen) Zeile
FTerminated := True; keinen Breakpoint setzen, der auch angesteuert wird?

[sirius]

@jfheins: Mist, naja virtuelle Biere sind ja recht günstig.
Aber dann hat TThread echt einen Designfehler (also noch einen mehr). Denn wo kann ich sonst zum Terminate noch etwas anfügen? Ich benutze diese Methode (hatte mich anfangs auch gewundert warum nicht virtuell, und mir dann meine, diese, Erklärung zurechtgelegt) recht häufg, wenn zum Beispiel mein Thread schläft auf Grund von:

• waitforsingleobject (o.ä)
• Winsock.recv
• ReadFile (bei Pipe)
• Warten auf Datenbank-Event
• ...

Wie macht man das dann?

@MatthiasR
Menu - Projektoptionen -> Debug-DCUs verwenden

[himitsu]

Die Prozedur Terminate setzt nur .Terminated auf true.
Ob und wie der Thread das nun intern beachtet ist egal.

Terminate/Terminated beendet die Threadverarbeitung nicht.
Terminated sagt nur "Hallo lieber Thread, würdest du dich bitte mal beenden?"

Also eigentlich sehe ich demnach auch keinen Grund, warum dieses überschreibar sein soll, da man es ja Threadintern dennoch anders behandeln kann (z.B. einfach ignorieren oder mit was Anderem verknüpfen).

Es muß ja nicht sein, daß man alles virtuell macht und so die VMT unnütz vergrößert.



- bei WaitForSingleObject und Co. läßt sich auch noch eine weitere Abbruchbedingung einbauen.
- ReadFile ließe sich Asynchron verarbeiten
- usw.

[MatthiasR]

Zitat von sirius:

@MatthiasR
Menu - Projektoptionen -> Debug-DCUs verwenden

Bei mir unter D7 wäre das dann: Projekt -> Optionen -> Compiler -> Mit Debug-DCUs. Nur bringt das bei mir irgendwie nichts. Der Breakpoint innerhalb TThread.Terminate ist immernoch durchgestrichen und die Zeile grün, statt rot.

Zitat von himitsu:

Also eigentlich sehe ich demnach auch keinen Grund, warum dieses überschreibar sein soll, da man es ja Threadintern dennoch anders behandeln kann (z.B. einfach ignorieren oder mit was Anderem verknüpfen).

Innerhalb meines TMeinThread.Execute wird ein mitunter sehr lange dauernder Download getätigt, der beim Aufruf von Terminate abgebrochen werden soll, damit überhaupt die Chance besteht, das Terminated-Flag auszuwerten und den Thread zu beenden. Das liebste wäre mir gewesen, wenn ein Aufruf von Terminate von außen ausreicht und das Unterbrechen des Downloads intern automatisch durchgeführt wird. Aber ich kann aus dem einen Terminate-Aufruf auch zwei Aufrufe machen. Terminate und anschließend eine zweite Methode "BrecheLaufendeDownloadsAb" oder so ähnlich.

[Stevie]

Zitat von himitsu:

Die Prozedur Terminate setzt nur .Terminated auf true.
Ob und wie der Thread das nun intern beachtet ist egal.

Terminate/Terminated beendet die Threadverarbeitung nicht.
Terminated sagt nur "Hallo lieber Thread, würdest du dich bitte mal beenden?"

Also eigentlich sehe ich demnach auch keinen Grund, warum dieses überschreibar sein soll, da man es ja Threadintern dennoch anders behandeln kann (z.B. einfach ignorieren oder mit was Anderem verknüpfen).

Wie "gut", dass FTerminated private und die property Terminated, die gottseidank protected ist nur read only ist. /irony=off

Zum Glück hat ein Thread ein OnTerminate Event, wie schade nur, dass das erst aufgerufen wird, nachdem der Thread terminated wurde, und nicht zu dem Zeitpunkt, wo Terminate aufgerufen wurde.

Wie man es auch dreht und wendet, es ist schlecht, dass Terminate nicht virtual ist.