Wenn man selber aufräumt, dann sieht man zumindestens, ob sich unbeabsichte Löcher verstecken.
Und wenn richtig aufgeräumt wird, dann sind Fehler beim Beenden minimiert.

z.B. Komponente auf Form, die beim Beenden auf etwas Globales in einer Unit zugreift ... wenn die Unit bereits ordentlich entladen wurde, dann würde es durt womöglich schön knallen.

Die Spiecherlecks werdn doch deshalb angezeigt, weil die Threads beim Beenden des Prozesses einfach abgeschossen werden und die von jedem Thread belegten Ressourcen nicht freigeben wurden.

Wenn man das nicht haben möchte, dann muss man sich eben selber um die Freigabe der Threads kümmern und nicht TThread.FreeOnTerminate := True; wegdelegieren.

BTW: Das hier ist grober Unfug:

zusammenfalten · markieren

Delphi-Quellcode:

Constructor TCalcThread.Create(Codec: TCodecType; Bitmap: TBitmap;
   OnCalcDone: TOnCalcDone);
Begin
   fSize:= -1; // ungültigen Wert vorgeben
   fCodec:= Codec; // Codec merken
   fOnCalcDone:=OnCalcDone; // Zeiger auf Ereignis merken
   fBitmap:=TBitmap.Create; // TBitmap anlegen
   fBitmap.Assign(Bitmap); // Bild kopieren
   FreeOnTerminate:=True; // Speicher selbst freigeben

   Inherited Create(True); // Thread erstellen
   Priority:= tpIdle; // geringe Priorität
// Resume; // "Start" löst Exception aus!
   Start; // "Resume" ist veraltet
End;

Während der Constructor abgearbeitet wird wird der Thread nicht loslaufen! Mit der Erkenntnis kann der Code wie folgt geschreiben werden:

zusammenfalten · markieren

Delphi-Quellcode:

Constructor TCalcThread.Create(Codec: TCodecType; Bitmap: TBitmap;
   OnCalcDone: TOnCalcDone);
Begin
   fSize := -1; // ungültigen Wert vorgeben
   fCodec := Codec; // Codec merken
   fOnCalcDone := OnCalcDone; // Zeiger auf Ereignis merken
   fBitmap := TBitmap.Create; // TBitmap anlegen
   fBitmap.Assign( Bitmap ); // Bild kopieren

   Inherited Create( False ); // Thread erstellen
   Priority := tpIdle; // geringe Priorität
   FreeOnTerminate := True; // Instanz selbst freigeben <- hmmm, nicht geschickt
End;

Der Destructor sollte allerdings wie folgt aufgebaut werden:

markieren

Delphi-Quellcode:

Destructor TCalcThread.Destroy;
Begin
   fOnCalcDone:=nil; // Zeiger löschen

   Inherited; // den Rest ausführen

   fBitmap.Free; // TBitmap selbst freigeben
End;

In TThread.Destroy wird unter anderem TThread.Terminate aufgerufen, weil der Thread ja noch aktiv sein kann. Wenn man dem Thread während der Abarbeitung die Ressource fBitmap unter dem A.... wegzieht, was kann dann passieren? Genau, es knallt. Also erst inherited , danach ist der Thread gesichert beendet und dann können alle Ressourcen ohne Reue freigeben werden!

Beim Beenden des Programms und Auswertung der Speicherlecks, müssten die Threads noch laufen und daher ist auch noch deren Speicher reserviert.
Erst nach Beenden/Freigeben/Entladen aller Delphi-Units und danach, beim Beenden des Prozesses, werden auch die restlichen Threads von Windows abgeschossen.

Aber im grunde stimme ich dem zu: selber die Threads beenden und sich danach das Programm beenden lassen.

Zitat von Sir Rufo:

...

zusammenfalten · markieren

Delphi-Quellcode:

Constructor TCalcThread.Create(Codec: TCodecType; Bitmap: TBitmap;
   OnCalcDone: TOnCalcDone);
Begin
   fSize := -1; // ungültigen Wert vorgeben
   fCodec := Codec; // Codec merken
   fOnCalcDone := OnCalcDone; // Zeiger auf Ereignis merken
   fBitmap := TBitmap.Create; // TBitmap anlegen
   fBitmap.Assign( Bitmap ); // Bild kopieren

   Inherited Create( False ); // Thread erstellen
   Priority := tpIdle; // geringe Priorität
   FreeOnTerminate := True; // Instanz selbst freigeben <- hmmm, nicht geschickt
End;

...

Gibt es einen bestimmten Grund, vom Pattern 'erst den Basiskonstruktor aufrufen' abzuweichen?

Weiterhin sollte der Threadersteller klar zwischen Konstruktor und Parametrierung unterscheiden. Imho ist es ein 'No Go', einem Konstruktor gleich Events mit zu übergeben. Ich würde zwischen Instantiierung, Parametrierung und Aufruf unterscheiden.

markieren

Delphi-Quellcode:

myThread := TmyThread.Create('stuff that cannot be changed');
myThread.OnCalcDone := OnCalcDone;
myThread.Start;

Imho ist der Aufrufer derjenige, der den Event an den Eventhandler flanscht. Das kann man natürlich auch noch vereinfachen:

markieren

Delphi-Quellcode:

Procedure TMyStuff.RunThread('stuff that cannot be changed');
var
  thread : TMyThread;
begin
  thread := TmyThread.Create('stuff that cannot be changed');
  thread.OnCalcDone := OnCalcDone;
  thread.Start;
end;

Der Eventhandler 'CalcDone' ist auch überflüssig, denn er wird eh nur am Ende des Threads aufgerufen. Da könnte man ja auch gleich das 'OnTerminate'-Ereignis nehmen, das eh im Aufruferkontext aufgerufen wird, ergo wäre das Synchronize auch überflüssig.