Zitat von iphi:

Wie kann ich feststellen, ob das Threadobjekt noch lebt?

Das FreeOnTerminate eben nicht verwenden.

Zitat von iphi:

Ich habe aber den Eindruck, dass MyThread nicht auf NIL gesetzt wird, wenn der Thread sich selbst auflöst

Richtig. Der Thread kann selbst auch gar nicht wissen, welche Variablen auf ihn zeigen.

Du musst dich entscheiden - Entweder du machst FreeOnTerminate, das heißt es ist Fire&Forget: Du startest den Thread und danach fasst du ihn nie wieder an. Deshalb macht es auch keinen Sinn ihn dann überhaupt in einer Variable zu speichern.

Oder du nutzt eben kein FreeOnTerminate, musst nachschauen wann er zu Ende ist, und wenn du ihn nicht mehr brauchst, gibst du ihn frei (.Destroy()).

von Außen kannst darfst du es garnicht feststellen, da die Variable per-se ungültig ist, weil der Thread schon weg sein könnte.
Also im Grunde darfst du den erstellten Thread garnicht erst in einer Variable speichern.
Das Selbe gilt auch für TThread.CreateAnonymus, welches ja auch FreeOnTerminate nutzt.

Dein Thread kann aber über eine "globale" Variable oder über ein Event nach außen durchgeben, dass er fertig ist.
Also du mußt das dann im Code rausgeben. (entweder im Destroy des Threads oder Try-Finally im Execute)

OnTerminate-Methode ist eine gute Idee!
Vielen Dank für die Aufklärung und Eure Hilfe!

Noch eine Verständnisfrage:

Macht FreeOnTerminate dann überhaupt irgendwann einen Sinn?
Wenn der Thread noch läuft, wenn das Hauptprogramm beendet wird, dann kommts zum Crash.
Wie fängt man sowas ab?

wenn du keine eigenes try-except im Execute hast, dann ist OnTerminatee auch die Stelle wo du self.FatalException oder war's .FatalError (kannst das einfach nach "Exception casten" )prüfen solltest.

Die VCL zeigt ja Exceptions an, aber TThread macht das nicht von sich aus.
Der fängt es nur ab, da wenn eine Exception bis zum Windows durchrauscht der ganze Prozess beendet wird.

Zitat von iphi:

Wenn der Thread noch läuft, wenn das Hauptprogramm beendet wird, dann kommts zum Crash.
Wie fängt man sowas ab?

Du kannst im Thread an entsprechender Stelle prüfen, ob dein Hauptprogramm gerade beendet wird und darauf reagieren. Im Hauptprogramm müstest du dann allerdings warten, bis alle Threads beendet sind.

Zitat von shebang:

Im Hauptprogramm müstest du dann allerdings warten, bis alle Threads beendet sind.

Das ist allerdings nicht so einfach.

Zitat von TigerLilly:

Das ist allerdings nicht so einfach.

Jo, "FreeOnTerminate", also kann/darf man nicht von außen prüfen.
Da kann man nur in einer "globalen" Variable/Liste seine aktiven Threads "zählen" und dann warten, bis der Zähler/Liste 0 ist (was vom Thread aus gesetzt wird, wenn er sich beendet).

Die RTL führt am Ende zwar ein Halt aus, was den ganzen Prozess beendet, also auch Threads "abschießt" (damit Windows eben nicht wartet, bis alle Threads beendet sind, inkl. dem Hauptthread),
aber wenn bis dahin beim Beenden die Threads z.B. auf die RTL/VCL zugreifen, aber die Finalization der Units bereits durch sind, auch der Speichermanager (FastMM) sich beendet hat, dann kann es natürlich knallen, drum sollte man oftmals eben auf seine Threads warten, bevor das Beenden des Programms weiterläuft.

Was ich bis jetzt alles gelesen habe ist etwas verwirrend.
Ich bin eh auf Kriegsfuß mit Delphis TThread, nutze nur noch Winapi CreateThread, da gibt es all diese Probleme nicht.

//edit
da kann ich auch abfragen ob mein thread handle noch existiert ohne irgendwelche probleme zu verursachen.

Bei TThread kann man das Handle oder die ThreadID auch prüfen,
aber durch FreeOnTerminate gibt sich der Thread selbst frei.

Und wenn dann in der zwischenzeit ein anderer Thread (egal ob RTL oder WinAPI) gestartet ist und die gleiche ThreadID/Handle hat, dann bringt dir das Prüfen darauf garnichts, weil es eben sein kann, dass es nicht "der" Thread ist.

[edit]
Man könnte das Thread-Handle "dupplizieren", um damit prüfen zu können.