Dein Hinweis war möglicherweise der Schubs in die richtige Richtung. Du meinst also etwa in der Art:

zusammenfalten · markieren

Delphi-Quellcode:

type
  TPingThread = class(TThread)
  private
    { Private-Deklarationen }
    FFB: TComplexClass;
  protected
    procedure Execute; override;
  public
    constructor Create(const AHost: string);
    destructor Destroy; override;
    property ReturnValue;
  end;

constructor TPingThread.Create(const AHost: string);
begin
  FreeOnTerminate:= True;
  FFB:= TComplexClass.Create(AHost);
  inherited Create(False);
end;

destructor TPingThread.Destroy;
begin
  FFB.Free;
  inherited;
end;

procedure TPingThread.Execute;
begin
  // Sleep nur zu Zwecken des Debugging
  Sleep(100);
  if Assigned(FFB) then
      ReturnValue:= Integer(FFB.Ping);
end;

Und dann in TfmMain

zusammenfalten · markieren

Delphi-Quellcode:

procedure TfmMain.FormCreate(Sender: TObject);
begin
    // Die Zuweisung von FHostName lasse ich mal mangels Relevanz weg; ist ein privates Attribut der Klasse
    FObject:= TComplexClass.Create(FHostName);
    PingThreadStart;
end;

procedure TfmMain.PingThreadStart;
begin
    FPingThread:= TPingThread.Create(FHostName);
    FPingThread.OnTerminate:= PingThreadDone;
end;

procedure TfmMain.PingThreadDone(Sender: TObject);
var
  Lsucc: Boolean;
begin
    Lsucc:= Boolean(FPingThread.ReturnValue);
    if Lsucc then
        Self.Caption:= 'Connected to ' + FObject.HostName
    else
        MessageBox(Self.Handle, PChar(FObject.HostName + ' not available'), '', MB_OK or MB_ICONINFORMATION);
end;

Das funktioniert. Zwei Sachen stören mich:

• Redundanz durch die Erzeugung der zweiten Instanz von TComplexClass in TPingThread und ggf. Zuweisung der nötigen Eigenschaften, auch wenn letzteres derzeit zum Glück nicht nötig ist.
• Es gibt Speicherlecks, wenn der Thread vorzeitig terminiert (während TPingThread.Execute noch läuft):
  markieren

  Code:

  ---------------------------
  Unexpected Memory Leak
  ---------------------------
  An unexpected memory leak has occurred. The unexpected small block leaks are:
  
  1 - 12 bytes: TObject x 1
  21 - 28 bytes: AnsiString x 1
  61 - 68 bytes: Unknown x 1
  69 - 76 bytes: TPingThread x 1
  269 - 284 bytes: TComplexClass x 1
  
  ---------------------------
  OK  
  ---------------------------
  Sind diese Lecks von Bedeutung?

Grüße
Dalai

In der Art..
Warum muß die eierlegende Wollmilchsauklasse dem Thread bekannt sein? Der Thread hat eine (kleine) Aufgabe zu erledigen, und dabei sollte er sich auf seinen Hinterhof beschränken, auf dem sich aber auch niemand anders herum treiben sollte. Und wenn er fertig ist, dies dem Mainthread mit einem Postmessage bekannt geben.

Gruß
K-H

Hi Dalai,

was heißt "vorzeitig terminieren"? Wenn du das Programm etwa mit dem Schließen X beendest? Wenn dem so sein sollte, dann müsste deine Anwendung einen Shutdown Prozess initiieren und alle noch laufenden Threads "sauber" beenden. Möglicherweise kann dann das Beenden der Anwendung auch ein paar Sekunden dauern. Einen Thread direkt wegschießen halte ich nicht für besonders gut und wüsste auch wenn ich ehrlich bin nicht wie ich das machen sollte.

Ansonsten beachte noch den Hinweis von p80286. Ein Thread bearbeitet nur eine kleine Teilaufgabe und muss auch dementsprechend nur die Informationen bekommen die er zum Arbeiten benötigt.

Zitat von p80286:

Warum muß die eierlegende Wollmilchsauklasse dem Thread bekannt sein?

Diese Frage steht mit der bereits genannten Redundanz in Verbindung, und ist eine Sache, die mir auch nicht gefällt. Im Prinzip könnte der Thread alles mit der Instanz der Klasse machen. Genau das wollte ich verhindern und nur die Methode Ping in den Thread geben. Aber ich werd mir mal das Klassendesign anschauen, ob ich da etwas weiter unten ansetzen kann. TComplexClass beinhaltet ein paar weitere Klassen, hoffentlich ist eine davon für das Ping zuständig (nein, ich habe den Code von TComplexClass nicht geschrieben, nur etwas angepasst).

Zitat:

Und wenn er fertig ist, dies dem Mainthread mit einem Postmessage bekannt geben.

Macht es denn einen Unterschied, ob ich das Arbeitsende mittels PostMessage, eigenem TNotifyEvent oder OnTerminate bekanntgebe?

Zitat von Aviator:

was heißt "vorzeitig terminieren"? Wenn du das Programm etwa mit dem Schließen X beendest?

Zum Beispiel.

Zitat:

Wenn dem so sein sollte, dann müsste deine Anwendung einen Shutdown Prozess initiieren und alle noch laufenden Threads "sauber" beenden.

Der Thread wird offenbar knallhart gekillt, ohne dass er davon etwas mitbekommt. Der Destruktur des Threads wird nicht durchlaufen (daher wohl auch die Lecks). Und nein, mein Code ruft an keiner Stelle FPingThread.Terminate oder ähnliches.

Zitat:

Einen Thread direkt wegschießen halte ich nicht für besonders gut und wüsste auch wenn ich ehrlich bin nicht wie ich das machen sollte.

Sehe ich auch so. Nur weiß ich nicht, wie ich das verhindern sollte, wenn der Delphi-Code das bereits tut.

Grüße
Dalai

Nach ein bisschen Umbau und der Nutzung nur jener Klasse, die wirklich nötig ist, sieht es nun so aus:

zusammenfalten · markieren

Delphi-Quellcode:

type
  TPingThread = class(TThread)
  private
    FClient: TClient;
    FOnPingDone: TNotifyEvent;
  protected
    procedure Execute; override;
  public
    constructor Create(const AHost: string);
    destructor Destroy; override;
    property OnPingDone: TNotifyEvent read FOnPingDone write FOnPingDone;
    property ReturnValue;
  end;
  
implementation
  
constructor TPingThread.Create(const AHost: string);
begin
  FOnPingDone:= nil;
  FreeOnTerminate:= True;
  FClient:= TClient.Create(AHost);
  FClient.Port:= 80;
  inherited Create(False);
end;

destructor TPingThread.Destroy;
begin
  FClient.Free;
  inherited;
end;

procedure TPingThread.Execute;
begin
  if Assigned(FClient) then
      ReturnValue:= Integer(FClient.IsAlive);
  if Assigned(FOnPingDone) then
      FOnPingDone(Self);
end;

und in TfmMain weise ich das OnPingDone-Event statt OnTerminate zu. Das Speicherleck beim vorzeitigen Beenden ist etwas kleiner:

markieren

Code:

---------------------------
Unexpected Memory Leak
---------------------------
An unexpected memory leak has occurred. The unexpected small block leaks are:

1 - 12 bytes: TObject x 1
21 - 28 bytes: AnsiString x 1
61 - 68 bytes: Unknown x 1
69 - 76 bytes: TPingThread x 1
93 - 100 bytes: TClient x 1

---------------------------
OK  
---------------------------

Kann man dagegen noch etwas tun? Ist zwar nicht besonders groß, aber stören tut's mich schon, und normalerweise räume ich den Krempel wieder auf, den ich erzeuge.

Grüße
Dalai

Sorry, falls der Eindruck entsteht, ich würde spammen, aber ich glaube, ich hab's. Außerdem fiel mir auf, dass OnTerminate mittels Synchronize gerufen wird, das selbstdefinierte Event OnPingDone aber nicht. Das hab ich gleich korrigiert, sonst gibt's später böse Fehler.

Thread:

zusammenfalten · markieren

Delphi-Quellcode:

type
  TPingThread = class(TThread)
  private
    FClient: TClient;
    FOnPingDone: TNotifyEvent;
    procedure CallOnPingDone;
  protected
    procedure Execute; override;
  public
    constructor Create(const AHost: string);
    destructor Destroy; override;
    property OnPingDone: TNotifyEvent read FOnPingDone write FOnPingDone;
    property ReturnValue;
  end;

procedure TPingThread.CallOnPingDone;
begin
  if Assigned(FOnPingDone) then
    FOnPingDone(Self);
end;

constructor TPingThread.Create(const AHost: string);
begin
  FOnPingDone:= nil;
  FreeOnTerminate:= True;
  FClient:= TClient.Create(AnsiString(AHost));
  FClient.Port:= 80;
  inherited Create(False);
end;

destructor TPingThread.Destroy;
begin
  FClient.Free;
  inherited;
end;

procedure TPingThread.Execute;
begin
  if Assigned(FClient) then
      ReturnValue:= Integer(FClient.IsAlive);
  if NOT Terminated then
      Synchronize(CallOnPingDone);
end;

Main:

zusammenfalten · markieren

Delphi-Quellcode:

type
  TfmMain = class(TForm)
  private
    FObject : TComplexClass;
    FPingThread : TPingThread;
    FPingThreadAlive : Boolean;
  end;

procedure TfmMain.FormCreate(Sender: TObject);
begin
    FObject:= TComplexClass.Create(FHostName);
    PingThreadStart;
end;

procedure TfmMain.FormClose(Sender: TObject; var Action: TCloseAction);
begin
    if FPingThreadAlive then begin
        FPingThreadAlive:= False;
        FPingThread.Terminate;
    end;
end;

procedure TfmMain.PingThreadStart;
begin
    FPingThreadAlive:= True;
    FPingThread:= TPingThread.Create(FHostName);
    FPingThread.OnPingDone:= PingThreadDone;
end;

procedure TfmMain.PingThreadDone(Sender: TObject);
var
  Lsucc: Boolean;
begin
    FPingThreadAlive:= False;
    Lsucc:= Boolean(FPingThread.ReturnValue);
    if Lsucc then
        Self.Caption:= 'Connected to ' + FObject.HostName
    else
        MessageBox(Self.Handle, PChar(FObject.HostName + ' not available'), '', MB_OK or MB_ICONINFORMATION);
end;

Das gibt laut FastMM keine Lecks, der Destruktor des Threads wird durchlaufen, und alle drei Fälle (erreichbar, nicht erreichbar, vorzeitig terminiert) funktionieren. Falls jemand Einwände dagegen hat, immer her damit; ich lerne gern dazu (sofern ich's verstehe ).

Grüße
Dalai

Ein Prozess ist nur ein Container für Threads. Da haben wir dem Mainthread und gegebenenfalls noch selbst erstellte weitere Threads. Wird der Prozess beendet, gibt Windows auch alle zugehörigen Ressourcen frei. Man "müllt" sich seinen Speicher also nicht voll. Windows ist wie die Mutter, die hinter einem aufräumt. Man kann jetzt also philosophieren, ob man es selbst tun sollte (Was "sauber" wäre.) oder es eben Windows überlässt.

Wenn ein Benutzer ein Prozess beendet, in dem er das Hauptfenster schließt, (Von "Abschießen" per Taskmanger wollen wir nicht reden, dann ist eh alles zu spät.) kann man diskutieren, ob man im OnClose des Hauptfensters noch allen Threads Bescheid sagt, sich beim nächst möglichen Zeitpunkt zu beenden oder ob man sagt: "Ach, egal. Windows macht das schon."

Zitat von Luckie:

Windows ist wie die Mutter, die hinter einem aufräumt.

In einigen Threads bei StackOverflow wurde auch darüber diskutiert, und es kamen vergleichbare Antworten, in der Art: kurz vor dem Ende eines Prozesses noch aufzuräumen ist vergebene Lebensmüh. Ich ahnte schon, dass die von FastMM erkannten Lecks in Wirklichkeit keine sind, weil selbiger (FastMM) aus dem Prozess verschwindet, bevor die Ressourcen danach wirklich wieder vom OS zurückgeholt werden.

Was ich mich aber frage: Wie kann ich sicher sein, dass die Ressourcen tatsächlich wieder freigegeben werden? Gibt's vielleicht doch Ressourcen-Typen, bei denen das nicht ganz so einfach ist?

Zitat von Aviator:

das sieht doch soweit ganz gut aus.

Das freut mich .

Zitat:

Du durchläufst deine Execute Methode und feuerst zum Schluss das OnPingDone Event. Du rufst aber zuerst Synchronize auf und prüfst dann, ob das Event überhaupt abonniert wurde. Somit wartet der Thread zuerst, ob er sich mit dem Main Thread Synchronisieren kann. Und das kann Zeit kosten.

Verstehe. Nur am Rande: Ich hatte zuerst eine Prüfung auf Assigned in Execute stehen, dachte mir aber "Wozu in Execute und CallOnPingDone prüfen? Einmal reicht doch.", und nahm es aus Execute raus. Aber deine Erklärung ist plausibel und ich werde es wieder reinnehmen.

Danke an alle Beteiligten für die kompetenten Antworten!

Grüße
Dalai

Hallo Dalai,

das sieht doch soweit ganz gut aus. Eine Sache die mir noch aufgefallen ist wäre folgende (das ist aber schon meckern auf ganz hohem Niveau):

Du durchläufst deine Execute Methode und feuerst zum Schluss das OnPingDone Event. Du rufst aber zuerst Synchronize auf und prüfst dann, ob das Event überhaupt abonniert wurde. Somit wartet der Thread zuerst, ob er sich mit dem Main Thread Synchronisieren kann. Und das kann Zeit kosten. Ich würde es umgekehrt machen. Das spart zwar nur ein paar Nano-/Milisekunden, aber wenn du dem Thread jetzt die Aufgaben geben würdest in einer Schleife mehrere Hosts abzufrühstücken, dann würde sich das u.U. bemerkbar machen.

Also könntest du aus deinem Code

zusammenfalten · markieren

Delphi-Quellcode:

procedure TPingThread.Execute;
begin
  if Assigned(FClient) then
    ReturnValue:= Integer(FClient.IsAlive);
  if NOT Terminated then
    Synchronize(CallOnPingDone);
end;

procedure TPingThread.CallOnPingDone;
begin
  if Assigned(FOnPingDone) then
    FOnPingDone(Self);
end;

folgenden Code machen:

zusammenfalten · markieren

Delphi-Quellcode:

procedure TPingThread.CallOnPingDone;
begin
  if Assigned(FOnPingDone) then
    FOnPingDone(Self);
end;

procedure TPingThread.Execute;
begin
  if Assigned(FClient) then
    ReturnValue:= Integer(FClient.IsAlive);
  if NOT Terminated then begin
    if Assigned(FOnPingDone) then begin
      Synchronize(CallOnPingDone);
    end;
  end;
end;

Oder gleich mit einer anonymen Methode das Synchronize aufrufen. Dann sparst du dir auch noch die Deklaration der CallOnPingDone Methode.

zusammenfalten · markieren

Delphi-Quellcode:

procedure TPingThread.Execute;
begin
  if Assigned(FClient) then
    ReturnValue:= Integer(FClient.IsAlive);
  if NOT Terminated then begin
    if Assigned(FOnPingDone) then begin
      Synchronize
      (
        procedure
        begin
          FOnPingDone(Self);
        end;
      );
    end;
  end;
end;

EDIT: Die Methode sind jetzt nur im Editor runtergetippt, sollten aber hoffentlich fehlerfrei sein. So viel habe ich jetzt ja auch nicht geändert.